• V20: 3CX Re-engineered. Get V20 for increased security, better call management, a new admin console and Windows softphone. Learn More.

Incorrect call duration - Outgoing calls

Status
Not open for further replies.

sanketgroup

Free User
Joined
Jun 28, 2012
Messages
97
Reaction score
0
Hello
Whenever we make Outside calls, call duration starts immediately as soon as it goes out to network.

Means, if we call any cell phone or outside call, call duration starts as soon as it starts ringing dialed number.
So even if called party is not picking up the phone and just ringing, 3cx count those seconds in call duration.

3cx should count call duration only from when called party has picked up the call.

Internal calls are working well. Extension to Extension calls has no such issue.
I am using patton gateway for outside calls via PRI line.

Thanx
 
I can think of 2 things.

1) If the number you are calling greets you with an IVR or some sort of message, then that call is indeed answered from that point onward, so in this case there is no fault.

2) For some reason the Patton device sends a 200 OK (SIP answer message) immediately.

To determine why this is happening, you would need to post some logs of a call that was answered immediately, at least from the Server Activity Log after you have set it to Verbose.
Also if you are comfortable with using Wireshark and know your way around viewing VoIP calls, that would also be a way to go.
 
No it is not IVR.
Even if it is ringing, it starts counting duration. so case (1) is not possible.

With other, following is the log.

01-Jul-2016 23:15:44.648 Leg L:32323.2[Line:10002>>9913333334] is terminated: Cause: BYE from PBX
01-Jul-2016 23:15:44.648 [CM503008]: Call(C:32323): Call is terminated
01-Jul-2016 23:15:44.647 Leg L:32323.1[Extn] is terminated: Cause: BYE from 192.168.2.146:51826
01-Jul-2016 23:15:30.619 Currently active calls - 1: [32323]
01-Jul-2016 23:15:26.183 [CM503007]: Call(C:32323): Line:10002>>9913333334 has joined, contact <sip:[email protected]:5060>
01-Jul-2016 23:15:26.182 [CM503007]: Call(C:32323): Extn:615 has joined, contact <sip:[email protected]:51826>
01-Jul-2016 23:15:26.181 L:32323.2[Line:10002>>9913333334] has joined to L:32323.1[Extn]
01-Jul-2016 23:15:26.181 NAT/ALG check:L:32323.2[Line:10002>>9913333334] RESPONSE 200 on 'INVITE' - basic check passed. No information for extended checks
 
here is wireshark logs
 

Attachments

  • duration1.zip
    9.1 KB · Views: 15
So from what I can see it is case #2.

As you can see above, the 3CX Server send then INVITE out (initiates the call) and 1 second later the Patton replies with a 200 OK (call answered) which is when the counter starts.

If this call was not answered after 1 second as the SIP messages imply, the Patton needs configuring.
Maybe someone with Patton experience could pitch in here, or you could contact Patton and ask them why.
 

Attachments

  • capture_screenshot.png
    capture_screenshot.png
    36.4 KB · Views: 1,126
ok, i contacted patton. They made one change in patton.
Now it resolved this issue about duration but raised another problem which they say it might belong to 3cx.

Patton has one option "Early media connect" which was enabled before.
This option send Connect (OK) message to 3cx and so 3cx was starting call duration as soon as ring starts.

Now we disabled this option in Patton and it does not send connect(ok) message to 3cx and patton sends message only when call is actually connected by ISDN side. So 3cx starts call duration only from when actual call is connected on ISDN side. Which is perfect.

HOWEVER
Now whatever precall announcement is being played by ISDN and passed by patton to 3cx, it is not being recognized by 3cx.

I contacted Patton about this. They reviewed patton log and explained everything in detail. There answer is as below:
############################################
Dear Sanket,

Thank you for the logs.

Attached is the information that I could gather from the log file.

We open the media as soon as we hear ringing.

It seems like there is some additional change done on 3CX which is preventing it to acknowledge when we open the media.

We received "PROGRESS" from the ISDN at 17:48:08 and then we sent "Session Progress" with the media information immediately and this was not acknowledged by 3CX.

Can you please see if there is any parameter that was tweeked in 3CX.

Regards,
Patton Support Desk
Technical Assistance Center - Melbourne
#######################################################################

i am also attaching patton log and support team commented in it.
Also attached is new wireshark log which is captured after changes on patton.
It seems 3CX is not acknowledging early media.
Pls help me to resolve this.

Thanx
 

Attachments

  • Log-192.168.2.12-20160706233607.log
    10.1 KB · Views: 12
  • v1.jpg
    v1.jpg
    176.7 KB · Views: 1,082
I know Early Media is handled normally when it comes to SIP Trunks, I would imagine the same happens with Gateways as well.

Can you upload a new capture file with an Early Media not being played?
 
pls find attached capture log.
 

Attachments

  • after early media connect.zip
    1.5 MB · Views: 12
Hi Nick
any update?

thanx
 
hoping for some solution.

Thanx
 
Hi Nick
Pls help.

Thanx
 
I contacted Patton also.
They deeply analyzed all logs and they found problem is from 3CX.

They asked me to contact 3CX to resolve this issue.

====Message from Patton====
Patton is sending SETUP message to the ISDN network, and patton received two CALL PROCEEDING messages.
The first message is without the in-band info which means we are not supposed to open the media stream.
The second message contains the in-band info and we open the media stream towards the 3CX system.
I think it is better that you should contact the 3CX support team and share this findings with them.
They are the one who have to handle it this way.

Since first message is without in-band info, 3CX starts playing own ring and it is ignoring subsequent second message with in-band information. In actual 3CX shall accept and process second message with in-band information.

Same thing you can see in wireshark log. SDP is being sent to 3CX before 183 and 3CX ignores those all SDP messages because it is before 183.
====

I am working on this issue since almost 50 days.
Patton was continuously working on this since last 25 days. Now 3CX pls help me to resolve this.


Thanx
 
183 Messages do not require an ACK response if memory serves, but we should be receiving the audio.

In the Gateway settings enable "PBX Delivers Audio" and disable "Supports Replaces" and "Supports Re-Invite" then make another capture that is answered and immediately sends 183 Early Media. This will allow us to also see the audio coming into the 3CX Server as now they are being sent directly to the phone.
 
Hi Nick
really thanx for reply.
Attached is new wireshark log as you said.
Enable "PBX Delivers Audio"
disable "Supports Replaces"
and "Supports Re-Invite"

awaiting for your reply.

Thanx
 

Attachments

  • pbx_deliver_audio_on-replaces_reinvice_off.rar
    588.9 KB · Views: 12
Although this is a hunch, but in the capture you sent I see ext 615 calling the external number. The Outbound Rule that was used to send the call to the GW, does it have more than one routes? If yes remove them all and leave only the first one which would be the GW, then try again.
 
That route has already only one route. NO other route was there for this outbound rule.

See image.
 

Attachments

  • Capture.JPG
    Capture.JPG
    53.1 KB · Views: 420
OK, so I think I know why this is happening, however I am not sure there is a solution. The 3CX software will process the first 180 or 183 message it receives and ignore any subsequent 180 or 183 messages and it will stick with the first one, that is of course until a final response arrives (like the 200 OK).

Now in your case, the first message that arrives is a 183 message, yes, but it is without SDP. This means that the audio transaction has not yet been established. Right after that, the Patton device sends a second 183 message that does contain SDP, but due to the fact that 3CX software will disregard any subsequent similar messages (explained above), nothing happens.

So, the only way for this to work is if somehow the Patton device can be made to send the first 180 or 183 message with SDP when needed.
 
exactly..you understood correct issue.

Problem is Patton denying to change anything in gateway by saying it is not under their control.
They said only 3CX can change to except subsequent 180 or 183.

They told it is not always necessary that first 180 or 183 must contain SDP, but 3CX shall able to handle subsequent SDP if not found in first.

BOTH are approved partners for each other, still i am feeling like tennis ball.
No one is providing solution and sending me to other court.
 
Patton are correct in the fact that it is not illegal to send a 183 without SDP and then send a 183 with SDP, it is just that the 3CX software processes like that.

The ideal solution for you is not possible to solve both problems. Let's not forget that with the default Patton settings send the 200 OK immediately, and now we probably know the reason why that is.
 
Status
Not open for further replies.
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.