Calls being dropped a couple of seconds after connecting

[Bibble]

Ok, I'm really stumped by this one. I'm attempting to configure 3CX in it's demo form to show that it works and performs the tasks required of it. Unfortunately, every time I place an incoming call, it connects, shows on the phone's called ID, and might even get around to ringing, but then the call gets terminated.

So far, I've tried fiddling with the STUN and port settings (both on the PBX and router, eventually returning to defaults), and checking through the logs for details.

Further Information:
Message received by the incoming phone (the one attempting to call the PBX) is "User Busy".

The logs for the calls are:

14:19:50.406  [CM503008]: Call(3): Call is terminated
14:19:50.265  [CM505001]: Ext.204: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [sipagent MAC:00-50-7F-39-3E-14 V:12202.26.1.03i-SIP] PBX contact: [sip:[email protected]:5060]
14:19:50.265  [CM503002]: Call(3): Alerting sip:[email protected]:5060
14:19:50.093  [CM503025]: Call(3): Calling Ext:Ext.204@[Dev:sip:[email protected]:5060]
14:19:50.093  [MS210002] C:3.2:Offer provided. Connection(transcoding mode): 192.168.1.27:7004(7005)
14:19:50.078  [CM503004]: Call(3): Route 1: Ext:Ext.204@[Dev:sip:[email protected]:5060]
14:19:50.078  [CM503010]: Making route(s) to <sip:[email protected]:5060>
14:19:50.078  [MS210000] C:3.1:Offer received. RTP connection: 217.14.138.154:55294(55295)
14:19:50.062  Remote SDP is set for legC:3.1
14:19:50.062  [CM505003]: Provider:[Draytel] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [Asterisk PBX] PBX contact: [sip:[email protected]:5060]
14:19:50.062  [CM503001]: Call(3): Incoming call from 07920585714@(Ln.10000@Draytel) to <sip:[email protected]:5060>
14:19:50.031  [CM503012]: Inbound out-of-office hours rule (604) for 10000 forwards to DN:204
14:19:50.031  Looking for inbound target: called=IBT-8249258-01205805604; caller=07920585714
14:19:50.031  [CM500002]: Info on incoming INVITE:
  INVITE sip:[email protected]:5060;rinstance=e260a5455c9ca78d SIP/2.0
  Via: SIP/2.0/UDP 217.14.138.154:5065;branch=z9hG4bK57be.61916274.0
  Via: SIP/2.0/UDP 217.14.138.127;branch=z9hG4bK57be.73cfc1f7.1
  Via: SIP/2.0/UDP 217.14.132.183;branch=z9hG4bK57be.63cfc1f7.0
  Via: SIP/2.0/UDP 77.240.48.141:5061;received=77.240.48.141;branch=z9hG4bK68e9dd20;rport=5061
  Max-Forwards: 67
  Record-Route: <sip:[email protected]:5065;lr=on;ftag=as257f6166>
  Record-Route: <sip:217.14.138.127;r2=on;lr=on;ftag=as257f6166>
  Record-Route: <sip:217.14.132.183;r2=on;lr=on;ftag=as257f6166>
  Record-Route: <sip:217.14.132.183;lr=on;ftag=as257f6166>
  Contact: <sip:[email protected]:5061>
  To: <sip:[email protected]>
  From: "07920585714"<sip:[email protected]:5061>;tag=as257f6166
  Call-ID: [email protected]
  CSeq: 102 INVITE
  Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
  Date: Mon, 28 Jun 2010 13:20:00 GMT
  Supported: replaces
  User-Agent: Asterisk PBX
  Content-Length: 0
  P-hint: inbound IBT, call to user
  P-RTP-Proxy: Yes

Does anyone have any idea where to go from here?

Any help is appreciated.

 

[mfm]

The ideal way to diagnose this is to create a wireshark capture and see what is being sent in between the two, once we know that we can, try and look for the the disconnect reason or send a screenshot of the ladder of SIP messages.

 

[Bibble]

Ok, did a wireshark capture, filtered for SIP calls, and the results are below:

From SIP Trunk to PBX:

|Time     | 217.14.138.154                        |
|         |                   | 192.168.1.27      |                   
|33.228   |         INVITE SDP ( g711A g711U GSM iLBC Exp. from Xe... PARC speex )          |SIP From: sip:[email protected]:5061 To:sip:[email protected]
|         |(5065)   ------------------>  (5060)   |
|33.331   |         100 Trying|                   |SIP Status
|         |(5065)   <------------------  (5060)   |
|33.438   |         CANCEL    |                   |SIP Request
|         |(5065)   ------------------>  (5060)   |
|33.541   |         180 Ringing                   |SIP Status
|         |(5065)   <------------------  (5060)   |
|33.542   |         200 OK    |                   |SIP Status
|         |(5065)   <------------------  (5060)   |
|33.542   |         487 Request Terminated          |SIP Status
|         |(5065)   <------------------  (5060)   |
|33.613   |         ACK       |                   |SIP Request
|         |(5065)   ------------------>  (5060)   |

From PBX to Extension:

|Time     | 192.168.1.27                          |
|         |                   | 192.168.1.74      |                   
|33.331   |         INVITE SDP ( g711U g711A GSM CN iLBC SPEEX tel...one-event)          |SIP From: sip:[email protected]:5060 To:sip:[email protected]
|         |(5060)   ------------------>  (5060)   |
|33.345   |         100 Trying|                   |SIP Status
|         |(5060)   <------------------  (5060)   |
|33.425   |         180 Ringing                   |SIP Status
|         |(5060)   <------------------  (5060)   |
|33.542   |         CANCEL    |                   |SIP Request
|         |(5060)   ------------------>  (5060)   |
|33.542   |         CANCEL    |                   |SIP Request
|         |(5060)   ------------------>  (5060)   |
|33.578   |         487 Request Cancelled          |SIP Status
|         |(5060)   <------------------  (5060)   |
|33.579   |         ACK       |                   |SIP Request
|         |(5060)   ------------------>  (5060)   |
|33.585   |         200 OK    |                   |SIP Status
|         |(5060)   <------------------  (5060)   |

From the looks of things, they appear to be being terminated from the SIP-side (CANCEL request sent at 33.438 from SIP to PBX).

Would than mean that the problem is in the way that Draytel are handling the calls?

Thanks.

 

[Bibble]

Ok, I took the information that Draytel were sending a cancel message to all the calls and gave them a call. Things suddenly went very busy on their end and now everything works.

Small amount of tech knowledge (mine and borrowed, thank you mfm) + a little intimidation = Job Done

 

[mfm]

Hey,

No thanks necessary, It was all you! Glad to hear you got everything sorted out.

 

[wzaatar]

May I suggest you 'mask' the phone numbers in your logs, just in case?

Cheers,

W.