Digital Receptionist Transfers

[ctownstud00]

Hello,

I am having problems getting the digital receptionist to transfer calls to internal extensions/voicemails. The digital receptionist picks up and plays the audio file I made stating the selection options. When the caller selects an option, the digital receptionist plays the "Please wait..." audio file and then the hold music begins to play. I notice in the System Extensions Status, the call is dropped after a short time and the caller just continues to hear hold music indefinitely.

I am using inbound SIP calling (IPKall.com) to my system. When someone calls, it attempts to ring a central house phone. If that phone is unanswered or unregistered, it forwards to the digital receptionist so that the caller can choose individual extensions to dial.

I don't have outbound calling. I don't have a VoIP/PSTN Gateway. I don't have a VoIP Provider. I don't have Inbound or Outbound Rules. I have other IPKall numbers attached to each extension for direct inbound calls, and they all work fine. I've tried playing with the PBX Delivers Audio, Supports Re-Invite, and Support 'Replaces' header options. Here is my Server Activity Log (with some personal numbers/domains masked with asterisks):

23-Aug-2014 16:02:32.571 Leg L:28.2[Ivr] is terminated: Cause: BYE from PBX
23-Aug-2014 16:02:32.571 [CM503008]: Call(C:28): Call is terminated
23-Aug-2014 16:02:32.570 Leg L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] is terminated: Cause: 408 Request Timeout/INVITE from local
23-Aug-2014 16:01:39.430 [CM503007]: Call(C:28): Ivr:800 has joined, contact <sip:[email protected]:40600>
23-Aug-2014 16:01:39.430 [CM503007]: Call(C:28): DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48 has joined, contact <sip:***@66.54.140.46:5060>
23-Aug-2014 16:01:39.429 L:28.2[Ivr] has joined to L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48]
23-Aug-2014 16:01:39.280 [CM503025]: Call(C:28): Calling T:Ivr:800@[Dev:sip:[email protected]:40600;rinstance=252c2a543c0bd6d0] for L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48]
23-Aug-2014 16:01:39.231 [CM503005]: Call(C:28): Forwarding: T:Ivr:800@[Dev:sip:[email protected]:40600;rinstance=252c2a543c0bd6d0]
23-Aug-2014 16:01:39.231 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] forwards call from Extn:100 to Ivr:800 based on rule Fwd[Available/NotReg]
23-Aug-2014 16:01:39.231 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] failed to reach Extn:100, reason Not Registered
23-Aug-2014 16:01:39.231 [CM503017]: Call(C:28): Target is not registered: Extn:100
23-Aug-2014 16:01:39.230 [CM503001]: Call(C:28): Incoming call from DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48 to <sip:kitchen@remote.***.com:5060>

I have researched this for several days without success, so I decided to turn to the community for assistance. This is my first attempt at setting up a PBX, so please keep that in mind and use verbiage and terminology that is "layman appropriate." =)

Thanks,
Sean

P.S. I'm not sure if the Extension Capabilities (where the PBX Delivers Audio, Supports Re-Invite, and Support 'Replaces' header options are) need to be changed both on my central house phone's extension (100 - "Kitchen") and the extension the digital receptionist is trying to connect to or just one or the other... I played with both unsuccessfully.

 

[leejor]

23-Aug-2014 16:02:32.570 Leg L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] is terminated: Cause: 408 Request Timeout/INVITE from local

Try enabling the Verbose setting on your logs, it may provider additional information to pinpoint why the call drops. It was almost a minute from when the call was connected to the DR and it dropped. Perhaps it did not detect correct DTMF and timed out? Have you confirmed that DTMF "gets through" ? Perhaps try an outside call direct to an extension, then have the caller send DTMF to see if it is audible. What happens if you call the DR directly from an internal extension, does it behave properly?

 

[ctownstud00]

Here are verbose logs as requested:

23-Aug-2014 16:02:32.571 L:28.2[Ivr]: Terminating targets, reason:
23-Aug-2014 16:02:32.571 Leg L:28.2[Ivr] is terminated: Cause: BYE from PBX
23-Aug-2014 16:02:32.571 L:28.2[Ivr] Sending: OnSendReq Send Req BYE from 0.0.0.0:0 tid=4a5fc5545e5ad34f Call-ID=ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.:
BYE sip:[email protected]:40600;rinstance=252c2a543c0bd6d0 SIP/2.0
Via: SIP/2.0/ ;branch=z9hG4bK-d8754z-4a5fc5545e5ad34f-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:***@127.0.0.1:5060>
To: <sip:[email protected]:5060>;tag=8c329019
From: "COSHOCTON OH"<sip:***@127.0.0.1:5060>;tag=5825cc4b
Call-ID: ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.
CSeq: 2 BYE
Content-Length: 0
23-Aug-2014 16:02:32.571 L:28.2[Ivr] Sending: OnSendResp Send 488/INVITE from 0.0.0.0:0 tid=df45443991633a18 Call-ID=ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.:
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP 127.0.0.1:40600;branch=z9hG4bK-d8754z-df45443991633a18-1---d8754z-;rport=40600
To: "COSHOCTON OH"<sip:***@127.0.0.1:5060>;tag=5825cc4b
From: <sip:[email protected]:5060>;tag=8c329019
Call-ID: ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.
CSeq: 2 INVITE
Content-Length: 0
23-Aug-2014 16:02:32.571 [CM503008]: Call(C:28): Call is terminated
23-Aug-2014 16:02:32.571 L:28.2[Ivr]: Terminating targets, reason: SIP ;cause=200 ;text="Call terminated on user request"
23-Aug-2014 16:02:32.570 Blocking refers for the Call(C:28)
23-Aug-2014 16:02:32.570 Call(C:28) is terminated
23-Aug-2014 16:02:32.570 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48]: Terminating targets, reason: SIP ;cause=408 ;text="Request Timeout"
23-Aug-2014 16:02:32.570 Leg L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] is terminated: Cause: 408 Request Timeout/INVITE from local
23-Aug-2014 16:02:32.570 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] got Terminated Recv 408/INVITE from 0.0.0.0:0 tid=d14b78127f615850 [email protected]:
SIP/2.0 408 Request Timeout
Via: SIP/2.0/UDP 10.0.1.10:5060;branch=z9hG4bK-d8754z-d14b78127f615850-1---d8754z-;rport
To: "COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48
From: <sip:kitchen@remote.***.com>;tag=b910a50d
Call-ID: [email protected]
CSeq: 2 INVITE
Content-Length: 0
23-Aug-2014 16:02:32.570 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] Sending: OnSendReq Send Req BYE from 0.0.0.0:0 tid=e610c14d9a71c822 [email protected]:
BYE sip:***@66.54.140.46:5060 SIP/2.0
Via: SIP/2.0/ ;branch=z9hG4bK-d8754z-e610c14d9a71c822-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:[email protected]:5060>
To: "COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48
From: <sip:kitchen@remote.***.com>;tag=b910a50d
Call-ID: [email protected]
CSeq: 3 BYE
Content-Length: 0
23-Aug-2014 16:02:00.361 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] Sending: OnSendReq Send Req INVITE from 0.0.0.0:0 tid=8d64de47f60d2028 [email protected]:
INVITE sip:***@66.54.140.46:5060 SIP/2.0
Via: SIP/2.0/ ;branch=z9hG4bK-d8754z-8d64de47f60d2028-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:[email protected]:5060>
To: "COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48
From: <sip:kitchen@remote.***.com>;tag=b910a50d
Call-ID: [email protected]
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
Content-Type: application/sdp
Supported: replaces
Content-Length: 271

v=0
o=3cxPS 238823669760 538397638657 IN IP4 98.30.144.27
s=3cxPS Audio call
c=IN IP4 98.30.144.27
t=0 0
m=audio 9000 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendonly
23-Aug-2014 16:02:00.360 Providing SDP for L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48]
23-Aug-2014 16:02:00.360 Reneg. from L:28.2[Ivr], offer
23-Aug-2014 16:02:00.360 Leg L:28.2[Ivr] raised event RecvdRemoteSdp
23-Aug-2014 16:02:00.360 Remote SDP is set for leg L:28.2[Ivr]
23-Aug-2014 16:02:00.360 Offer SDP arrived on Leg L:28.2[Ivr];
OnOffer Recv Req INVITE from 127.0.0.1:40600 tid=df45443991633a18 Call-ID=ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.:
INVITE sip:***@127.0.0.1:5060 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:40600;branch=z9hG4bK-d8754z-df45443991633a18-1---d8754z-;rport=40600
Max-Forwards: 70
Contact: <sip:[email protected]:40600;rinstance=252c2a543c0bd6d0>
To: "COSHOCTON OH"<sip:***@127.0.0.1:5060>;tag=5825cc4b
From: <sip:[email protected]:5060>;tag=8c329019
Call-ID: ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
Content-Type: application/sdp
Supported: replaces
User-Agent: 3CX IVR
Content-Length: 377

v=0
o=3cxVCE 383534460 287786641 IN IP4 127.0.0.1
s=3cxVCE Audio Call
c=IN IP4 127.0.0.1
t=0 0
m=audio 40650 RTP/AVP 0 8 3 13 9 110 99 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:13 CN/8000
a=rtpmap:9 G722/8000
a=rtpmap:110 iLBC/8000
a=rtpmap:99 SPEEX/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendonly
23-Aug-2014 16:01:39.627 Session 585 of leg L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] is confirmed
23-Aug-2014 16:01:39.627 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] got Confirmed Recv Req ACK from 66.54.140.46:5060 tid=0f868511 [email protected]:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 66.54.140.46:5060;branch=z9hG4bK0f868511;rport=5060
Max-Forwards: 70
Contact: <sip:***@66.54.140.46:5060>
To: <sip:kitchen@remote.***.com>;tag=b910a50d
From: "COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48
Call-ID: [email protected]
CSeq: 102 ACK
User-Agent: IPKall
Content-Length: 0
23-Aug-2014 16:01:39.430 [CM503007]: Call(C:28): Ivr:800 has joined, contact <sip:[email protected]:40600>
23-Aug-2014 16:01:39.430 [CM503007]: Call(C:28): DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48 has joined, contact <sip:***@66.54.140.46:5060>
23-Aug-2014 16:01:39.430 Session 585 of leg L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] is connected
23-Aug-2014 16:01:39.430 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] got Connected.UAS Send 200/INVITE from 0.0.0.0:0 tid=2646ecea [email protected]:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 66.54.140.46:5060;branch=z9hG4bK2646ecea;rport=5060
Contact: <sip:[email protected]:5060>
To: <sip:kitchen@remote.***.com>;tag=b910a50d
From: "COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48
Call-ID: [email protected]
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
Content-Type: application/sdp
Supported: replaces
User-Agent: 3CXPhoneSystem 12.0.36097.670 (34969)
Content-Length: 259

v=0
o=3cxPS 212953202688 252379660289 IN IP4 98.30.144.27
s=3cxPS Audio call
c=IN IP4 98.30.144.27
t=0 0
m=audio 9000 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
23-Aug-2014 16:01:39.430 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] Sending: OnSendResp Send 200/INVITE from 0.0.0.0:0 tid=2646ecea [email protected]:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 66.54.140.46:5060;branch=z9hG4bK2646ecea;rport=5060
Contact: <sip:[email protected]:5060>
To: <sip:kitchen@remote.***.com>;tag=b910a50d
From: "COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48
Call-ID: [email protected]
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
Content-Type: application/sdp
Supported: replaces
Content-Length: 259

v=0
o=3cxPS 212953202688 252379660289 IN IP4 98.30.144.27
s=3cxPS Audio call
c=IN IP4 98.30.144.27
t=0 0
m=audio 9000 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
23-Aug-2014 16:01:39.429 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48]: Terminating targets, reason: SIP ;cause=200 ;text="Call completed elsewhere"
23-Aug-2014 16:01:39.429 L:28.2[Ivr] has joined to L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48]
23-Aug-2014 16:01:39.429 Session 588 of leg L:28.2[Ivr] is connected
23-Aug-2014 16:01:39.429 L:28.2[Ivr] got Connected.UAC Recv 200/INVITE from 127.0.0.1:40600 tid=cb1fab46fe145140 Call-ID=ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-d8754z-cb1fab46fe145140-1---d8754z-;rport=5060
Contact: <sip:[email protected]:40600;rinstance=252c2a543c0bd6d0>
To: <sip:[email protected]:5060>;tag=8c329019
From: "COSHOCTON OH"<sip:***@127.0.0.1:5060>;tag=5825cc4b
Call-ID: ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
Content-Type: application/sdp
Supported: replaces
User-Agent: 3CX IVR
Content-Length: 250

v=0
o=3cxVCE 383534460 287786640 IN IP4 127.0.0.1
s=3cxVCE Audio Call
c=IN IP4 127.0.0.1
t=0 0
m=audio 40650 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
23-Aug-2014 16:01:39.429 Remote SDP is set for leg L:28.2[Ivr]
23-Aug-2014 16:01:39.429 Answer SDP arrived on Leg L:28.2[Ivr];
OnAnswer Recv 200/INVITE from 127.0.0.1:40600 tid=cb1fab46fe145140 Call-ID=ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-d8754z-cb1fab46fe145140-1---d8754z-;rport=5060
Contact: <sip:[email protected]:40600;rinstance=252c2a543c0bd6d0>
To: <sip:[email protected]:5060>;tag=8c329019
From: "COSHOCTON OH"<sip:***@127.0.0.1:5060>;tag=5825cc4b
Call-ID: ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
Content-Type: application/sdp
Supported: replaces
User-Agent: 3CX IVR
Content-Length: 250

v=0
o=3cxVCE 383534460 287786640 IN IP4 127.0.0.1
s=3cxVCE Audio Call
c=IN IP4 127.0.0.1
t=0 0
m=audio 40650 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
23-Aug-2014 16:01:39.429 L:28.2[Ivr] Sending: OnSendReq Send Req ACK from 0.0.0.0:0 tid=0e102c799807d82e Call-ID=ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.:
ACK sip:[email protected]:40600;rinstance=252c2a543c0bd6d0 SIP/2.0
Via: SIP/2.0/ ;branch=z9hG4bK-d8754z-0e102c799807d82e-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:***@127.0.0.1:5060>
To: <sip:[email protected]:5060>;tag=8c329019
From: "COSHOCTON OH"<sip:***@127.0.0.1:5060>;tag=5825cc4b
Call-ID: ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.
CSeq: 1 ACK
Content-Length: 0
23-Aug-2014 16:01:39.429 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] Sending: OnSendResp Send 180/INVITE from 0.0.0.0:0 tid=2646ecea [email protected]:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 66.54.140.46:5060;branch=z9hG4bK2646ecea;rport=5060
Contact: <sip:kitchen@remote.***.com>
To: <sip:kitchen@remote.***.com>;tag=b910a50d
From: "COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48
Call-ID: [email protected]
CSeq: 102 INVITE
Content-Length: 0
23-Aug-2014 16:01:39.429 Provisional response arrived for session 588 of Leg L:28.2[Ivr]
23-Aug-2014 16:01:39.429 L:28.2[Ivr] got Provisional Recv 180/INVITE from 127.0.0.1:40600 tid=cb1fab46fe145140 Call-ID=ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-d8754z-cb1fab46fe145140-1---d8754z-;rport=5060
Contact: <sip:[email protected]:40600;rinstance=252c2a543c0bd6d0>
To: <sip:[email protected]:5060>;tag=8c329019
From: "COSHOCTON OH"<sip:***@127.0.0.1:5060>;tag=5825cc4b
Call-ID: ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.
CSeq: 1 INVITE
User-Agent: 3CX IVR
Content-Length: 0
23-Aug-2014 16:01:39.429 [CM503002]: Call(C:28): Alerting Ivr:800 by contact <sip:[email protected]:40600>
23-Aug-2014 16:01:39.428 UacSession 588 has formed leg L:28.2[Ivr]
23-Aug-2014 16:01:39.280 [CM503025]: Call(C:28): Calling T:Ivr:800@[Dev:sip:[email protected]:40600;rinstance=252c2a543c0bd6d0] for L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48]
23-Aug-2014 16:01:39.280 Route to L:28.2[Ivr] sends Invite-OUT Send Req INVITE from 0.0.0.0:0 tid=16607653f50e2c76 Call-ID=ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.:
INVITE sip:[email protected]:40600;rinstance=252c2a543c0bd6d0 SIP/2.0
Via: SIP/2.0/ ;branch=z9hG4bK-d8754z-16607653f50e2c76-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:***@127.0.0.1:5060>
To: <sip:[email protected]:5060>
From: "COSHOCTON OH"<sip:***@127.0.0.1:5060>;tag=5825cc4b
Call-ID: ZWNlYWM2NzgwOWIyZjYyNjQ2YmY4ODExYTQ1ZTk1MWY.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
Content-Type: application/sdp
Supported: replaces
Content-Length: 350

v=0
o=3cxPS 442046087168 45147488257 IN IP4 127.0.0.1
s=3cxPS Audio call
c=IN IP4 127.0.0.1
t=0 0
m=audio 7054 RTP/AVP 0 8 3 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSuppff - - - -
a=ptime:20
a=sendrecv
23-Aug-2014 16:01:39.278 Added leg L:28.2[Ivr]
23-Aug-2014 16:01:39.231 [Flow] Call(C:28): making call from L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] to T:Ivr:800@[Dev:sip:[email protected]:40600;rinstance=252c2a543c0bd6d0]
23-Aug-2014 16:01:39.231 [CM503005]: Call(C:28): Forwarding: T:Ivr:800@[Dev:sip:[email protected]:40600;rinstance=252c2a543c0bd6d0]
23-Aug-2014 16:01:39.231 [Flow] L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48]: Build targets for Ivr:800
23-Aug-2014 16:01:39.231 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] forwards call from Extn:100 to Ivr:800 based on rule Fwd[Available/NotReg]
23-Aug-2014 16:01:39.231 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] failed to reach Extn:100, reason Not Registered
23-Aug-2014 16:01:39.231 Leg L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48]: Refreshing OutCID from endpoint Extn:100 = []
23-Aug-2014 16:01:39.231 [CM503016]: Call(C:28): Attempt to reach <sip:kitchen@remote.***.com:5060> from DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48 has failed. Reason: Not Registered
23-Aug-2014 16:01:39.231 [CM503017]: Call(C:28): Target is not registered: Extn:100
23-Aug-2014 16:01:39.231 [Flow] Call(C:28): has built target endpoint: Extn:100 for call from L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48]
23-Aug-2014 16:01:39.231 [CM503010]: Call(C:28): Making route(s) from DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48 to <sip:kitchen@remote.***.com:5060>
23-Aug-2014 16:01:39.231 Remote SDP is set for leg L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48]
23-Aug-2014 16:01:39.231 [CM500002]: Call(C:28): Info on incoming INVITE from DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48:
Invite-IN Recv Req INVITE from 66.54.140.46:5060 tid=2646ecea [email protected]:
INVITE sip:kitchen@remote.***.com SIP/2.0
Via: SIP/2.0/UDP 66.54.140.46:5060;branch=z9hG4bK2646ecea;rport=5060
Max-Forwards: 70
Contact: <sip:***@66.54.140.46:5060>
To: <sip:kitchen@remote.***.com>
From: "COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48
Call-ID: [email protected]
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Content-Type: application/sdp
Date: Sat, 23 Aug 2014 20:01:46 GMT
Supported: replaces
User-Agent: IPKall
Content-Length: 332

v=0
o=root 1312 1312 IN IP4 66.54.140.46
s=session
c=IN IP4 66.54.140.46
t=0 0
m=audio 18492 RTP/AVP 0 8 3 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSuppff - - - -
a=ptime:20
a=sendrecv
23-Aug-2014 16:01:39.230 [CM503001]: Call(C:28): Incoming call from DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48 to <sip:kitchen@remote.***.com:5060>
23-Aug-2014 16:01:39.227 IncomingCall: C:28 from <sip:***@66.54.140.46:5060> to <sip:kitchen@remote.***.com:5060>
23-Aug-2014 16:01:39.227 Added leg L:C:28.1[No endpoint yet]

I have only attempted calling the DR internally by pressing the option for connecting back to my own extension, which works as expected, connecting me into my voicemail. Tried outside call to direct extension and DTMF tones sounded extremely short and cut off, so to speak. I'm using a soft phone to test and the soft phone only allows quick pressing (single left mouse clicking) of the numbers on the keypad, versus being able to hold them down for an extended period. If this were the issue, would the DR respond with "Please hold while I transfer your call..." and put me on hold?

Thanks,
Sean

 

[leejor]

Do you have multiple extensions that outside callers can cause the DR to transfer them to, or just one. I'm just wondering if you get the same behaviour. I'm wondering if there is an issue with the extension that you are trying to connect to.

If you dial 800, from an extension, you should connect to the DR, can you then dial, and be transferred to, another extension? What about dialling 999 (voicemail) from outside.

Many times, over VoIP, DTMF tends to be short bursts. In fact, most mobiles and electronic keypads will do this, about the only thing that doesn't is the older analogue phones with very simple DTMF keypads (no integrated circuit). Even that type, when converted to SIP messaging, is shortened to a burst. As long as the volume is not too low, it should work.

 

[ctownstud00]

Do you have multiple extensions that outside callers can cause the DR to transfer them to, or just one. I'm just wondering if you get the same behaviour. I'm wondering if there is an issue with the extension that you are trying to connect to.

If you dial 800, from an extension, you should connect to the DR, can you then dial, and be transferred to, another extension? What about dialling 999 (voicemail) from outside.

Many times, over VoIP, DTMF tends to be short bursts. In fact, most mobiles and electronic keypads will do this, about the only thing that doesn't is the older analogue phones with very simple DTMF keypads (no integrated circuit). Even that type, when converted to SIP messaging, is shortened to a burst. As long as the volume is not too low, it should work.

Yes, there are multiple extensions. They all have the same (bad) behaviour. I don't think it's the DTMF issue. I had a friend attempt with a phone that was capable of longer DTMF tones and the system acted the same.

I also noticed that when I use the DR internally to transfer to another extension, I hear different hold music... Hmm...

Sean

 

[leejor]

I'm not that clear on the set-up of your network. I'm seeing things like this (the high lighted part).

23-Aug-2014 16:01:39.230 [CM503001]: Call(C:28): Incoming call from DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48 to <sip:kitchen@remote.***.com:5060>

Is the the extension that the IPKall came to originally?

I'm also not seeing any 192.168.XX.XX types IP's. Is this being run on a remote server?

Did this ever work? What version of 3CX are you using?

Have you tried having IPKall send 800, so the call goes directly to the DR?

 

[ctownstud00]

I have v12.0.36097.670. It is my first time setting up a PBX. I am using a remote A name DNS pointer from my domain host to point to my static public IP address so that I don't have to remember the numbers. It works successfully with several other servers. I can successfully call each extension directly from an external PSTN. I have hidden the domain name and the telephone number in some cases of my logs.

I also just noticed that when placing a user on Hold, it seems that I can't get them back. I think that it may be when the DR places the user on Hold to transfer them, it is hitting some kind of issue. Perhaps that's where the trouble lies.

Sean

 

[ctownstud00]

I read this.

One of gateways the call passes through is interpreting the on hold indication rather than passing it along to the next gateway.

(http://www.dslreports.com/forum/remark,27090033)

Perhaps my routing setup is more pertinent here than not; I use IPKall (http://phone.ipkall.com) to send SIP calls to my 3CX. Perhaps it is seeing the "hold," as this gentleman suggested, and somehow not seeing the "unhold." It seems that when I place an external call on hold, it is impossible to get it back. The different hold music could be from the IPKall server if this is the case.

Sean

 

[ctownstud00]

This thread seems to suggest an issue along the same lines, but I'm really unsure how to configure this. I don't see it anywhere in the settings...

"unknown" music on hold is provided by VoIP provider or by PSTN gateway.
To avoid it, you need to configure connection with provider/gateway as "supports re-Invites=off" and "supports replaces"=off
"supports re-Invites=off" and "supports replaces"=off are the standard settings for VoIP providers and you should not change them.

(http://www.3cx.com/forums/crazy-mysterious-on-hold-music-18829.html)

Sean

 

[leejor]

Dis you ever try sending IPKall directly to the DR?

I use the service myself but just send it to a Ring Group, also using a Dynamic DNS. It very well may be something to do with their service, if other provider (routing calls the same way) are working just fine. I'm not, however, aware of them providing any music on hold.

 

[ctownstud00]

Dis you ever try sending IPKall directly to the DR?

I use the service myself but just send it to a Ring Group, also using a Dynamic DNS. It very well may be something to do with their service, if other provider (routing calls the same way) are working just fine. I'm not, however, aware of them providing any music on hold.

The DR doesn't have an externally accessible SIP address, I think. I tried it once (setting my IPKall number to point to the DR extension) and it didn't work. You use IPKall with 3CX and you can place calls on Hold and Resume them normally?

Sean

 

[lneblett]

The "Please wait while I transfer your call....." is the response from the DR when either seeing a valid DTMF selection, or reaching the timeout and then sending the call to whatever setting you have selected for such a case. If you have a worry about the DTMF then you can test by pressing an invalid selection in which case an error message will occur, or press 999 or other applicable entry for VM and see. You should also be able to time the issue and see if a timeout is occurring.

As far as the hold and un-hold, is this not a separate issue?

From the looks of the log, the call is coming in and initially being directed to ext. 100. Because 100 is not registered, the call is then diverted to the IVR/DR. From there, it does reach the IVR, but it appears like there is a timeout.
Please note the following:
23-Aug-2014 16:02:32.570 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] Sending: OnSendReq Send Req BYE from 0.0.0.0:0 tid=e610c14d9a71c822 [email protected]:
BYE sip:***@66.54.140.46:5060 SIP/2.0
Via: SIP/2.0/ ;branch=z9hG4bK-d8754z-e610c14d9a71c822-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:[email protected]:5060>
To: "COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48
From: <sip:kitchen@remote.***.com>;tag=b910a50d
Call-ID: [email protected]
CSeq: 3 BYE
Content-Length: 0
23-Aug-2014 16:02:00.361 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] Sending: OnSendReq Send Req INVITE from 0.0.0.0:0 tid=8d64de47f60d2028 [email protected]:
INVITE sip:***@66.54.140.46:5060 SIP/2.0


Note the time difference is ~ 30 seconds.

Then, later on, there is a 488 response code indicating that there was something in the SIP messages that was not liked. My immediate suggestion is to turn off Re-invite and Replaces and then direct the call to a working extension rather than the DR so as to minimize the amount of handling that goes on. Test that way and see if successful and also if the hold issue & strange music are still in play.

 

[ctownstud00]

The "Please wait while I transfer your call....." is the response from the DR when either seeing a valid DTMF selection, or reaching the timeout and then sending the call to whatever setting you have selected for such a case. If you have a worry about the DTMF then you can test by pressing an invalid selection in which case an error message will occur, or press 999 or other applicable entry for VM and see. You should also be able to time the issue and see if a timeout is occurring.

As far as the hold and un-hold, is this not a separate issue?

From the looks of the log, the call is coming in and initially being directed to ext. 100. Because 100 is not registered, the call is then diverted to the IVR/DR. From there, it does reach the IVR, but it appears like there is a timeout.
Please note the following:
23-Aug-2014 16:02:32.570 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] Sending: OnSendReq Send Req BYE from 0.0.0.0:0 tid=e610c14d9a71c822 [email protected]:
BYE sip:***@66.54.140.46:5060 SIP/2.0
Via: SIP/2.0/ ;branch=z9hG4bK-d8754z-e610c14d9a71c822-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:[email protected]:5060>
To: "COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48
From: <sip:kitchen@remote.***.com>;tag=b910a50d
Call-ID: [email protected]
CSeq: 3 BYE
Content-Length: 0
23-Aug-2014 16:02:00.361 L:28.1[DirSipirectSIP<<"COSHOCTON OH"<sip:***@66.54.140.46:5060>;tag=as07ceee48] Sending: OnSendReq Send Req INVITE from 0.0.0.0:0 tid=8d64de47f60d2028 [email protected]:
INVITE sip:***@66.54.140.46:5060 SIP/2.0


Note the time difference is ~ 30 seconds.

Then, later on, there is a 488 response code indicating that there was something in the SIP messages that was not liked. My immediate suggestion is to turn off Re-invite and Replaces and then direct the call to a working extension rather than the DR so as to minimize the amount of handling that goes on. Test that way and see if successful and also if the hold issue & strange music are still in play.

Thanks for your reply. I don't think the Hold/Resume is a separate issue, I think they are related or one in the same. Even when I call from an external location to a working extension, whenever I place the external call on hold, the strange music (probably from IPKall) is being played and I can't pick the call back up, it gets disconnected soon after. I've tried disabling the Re-invite and Replaces everywhere I can think of. I even created a new VoIP Provider with the IPKall information and turned off Re-invites and Replaces there to no avail.

Sean

 

[lneblett]

Sorry, I did mean to imply that the hold issue is not related nor important, but rather another symptom. You did not mention it in the initial post, but sometime later. As a result, my thought process was to focus on the connectivity issue - getting a call into the system and being able to effectively converse from outside to in.

Apparently you can do this as you indicated in the last post, that you can connect directly to an extension with no issue. It also seems that the DTMF is being received by 3CX and the system is doing something that interferes with the desired action. By this I mean, that the system is apparently putting the call on-hold, given that the "Please wait......" message is being heard. Then, the "strange" on-hold music is heard by the caller....presumably while waiting for the system to complete the transfer. The implication is that the somehow the IPKALL system is receiving a "hold" and provides the music, but then because the call is being managed by IPKALL there is no way to retrieve the call.

As I do not use IPKALl, I can't really emulate the issue, but perhaps Leejor can confirm the behavior with his setup. It may be necessary to do a wireshark to see everything that is going on between 3CX and IPKALL. It is somewhat like IPKALL is actibg like a hosted solution. I did some looking around on the web and I could not find any reference to where IPKALL provides MOH. The system only comes with one MOH wav file, and you can add others and vary how they playback, but I am assuming that you never messed with it.

 

[leejor]

IPKall is a very simple , bare bones service. I'm not aware of any sort of hold option that is available.Certainly nothing is mentioned on the site. For myself, the calls go direct to a ring group and are either answered, or go off to voicemail. I really don't get a lot of calls over that service.

I rarely, if ever, put a call on hold and never have for IPKall.

Once a VoIP call comes into 3CX, and is put on hold, in theory, the call should simply be seen by the originator as still active.

As mentioned, Wireshark would confirm whether any SIP message are sent back to IPKall. when is was initiated.

I may be wrong, but I seem to recall , in the past, when "strange" hold music made an appearance, it ended up originating with the set that was used to hold the call.

 

[ctownstud00]

IPKall is a very simple , bare bones service. I'm not aware of any sort of hold option that is available.Certainly nothing is mentioned on the site. For myself, the calls go direct to a ring group and are either answered, or go off to voicemail. I really don't get a lot of calls over that service.

I rarely, if ever, put a call on hold and never have for IPKall.

Once a VoIP call comes into 3CX, and is put on hold, in theory, the call should simply be seen by the originator as still active.

As mentioned, Wireshark would confirm whether any SIP message are sent back to IPKall. when is was initiated.

I may be wrong, but I seem to recall , in the past, when "strange" hold music made an appearance, it ended up originating with the set that was used to hold the call.

Could you try putting an IPKall call on hold to see what happens? I have not used Wireshark before, but when I get home from work, I may try to use it to help nail this down...

Thanks for your replies,
Sean

 

[leejor]

I can try this evening. I have a few SPA942 with a hold key which does make use of the 3CX hold music when used on an extension to extension call.

 

[ctownstud00]

This would need to be from an external source being routed through IPKall. I appreciate your help and I anticipate hearing your results later this evening!

Sean

 

[leejor]

Understood. I will attempt a call out to the IPKall number, answer it and then out it on hold.

 

[leejor]

Placed a call to my IPKall number, goes to a ring group, answered on an SPA942, put the call on hold, got the 3CX hold music. I took the call off hold and placed it back again (repeated several times) using the hold key on the set, no problems at all.