Calls routed to voicemail remain connected

[Ads]

I'm evaluating 3cx v7.1 RC2 and whenever voicemail picks up an un-answered call the call can remain connected for
exactly 31:27mins. I've found this happens when an incoming caller listens to the message, does nothing for a short
period then hangs up. If the caller hangs up quickly or correctly presses the # and 0 the the call terminates correctly.

I've read in this forum that a workaround of a 120secs timeout existsts in RC3 but mentions an FXO gateway which I'm
not using (I use SIP trunk only), will my problem be fixed by RC3 or is there another solution.

Many thanks,
Ads.

 

[LeonidasG_3CX]

I did a couple of tests on it

Called *4100.
The Call Ended at 2Minutes and 32 Seconds.

Called 999
The call Ends when you hear the Prompt 5 times.

Called an Extension with a Forwarding Rule: If no answer > Forward to Voice Mail
The call ends at around 2minutes and 32 seconds.

Did i miss something?

 

[Ads]

I've only tested this by calling in from an external line eg. PSTN landline, I then listen to the
message talk for 30secs and then hangup, then I see the Voiptrunk remains connected for
precisely for 31 mins 27 secs. If I hangup before 30secs eg. 20secs then the the Trunk
disconnects immediately as expected.

I haven't tested this behaviour from internal extension phones but I'll try next time I'm in
the office.

Ads.

 

[Ads]

Update:

I upgraded the installation to Build Version 7.1.6589 and now if I place an external call to the system, reach voicemail and
then hangup after 30 seconds or so the voip trunk remains connected for just 2m 30s as LeonidasG above discovered.

I still would expect the call to disconnect immediately but this behaviour is a big improvement over the 31m 27 secs I was
experiencing previously. If the caller presses # to end the call to voicemail the trunk disconnects immediately.

For information this latest installation was clean on a fresh install of windows server 2003 x86, using cassini but restoring the previous configuration.

Ads.

 

[SY]

Ads,

PBX ends the call right after one of participats requested it...
Does your "sip trunk" send any requests to PBX when call is ended by remote participant(connected to PBX using SIP trunk)?

Thanks

 

[Ads]

Hi Sy,

If you make an remote call to 3CX and get connected to a 3CX extension phone the remote caller can hang up any time
and that call disconnects immediately. An external call only appears to hang when its routed through to voicemail.

I would say that my sip trunk provider (voiptalk.org) is sending the appropriate 'call termination' signals but I cant
be sure.

Ads.

 

[SY]

Hi Sy,

If you make an remote call to 3CX and get connected to a 3CX extension phone the remote caller can hang up any time
and that call disconnects immediately. An external call only appears to hang when its routed through to voicemail.

I would say that my sip trunk provider (voiptalk.org) is sending the appropriate 'call termination' signals but I cant
be sure.

Ads.

Experiment is simple. Receive call from SIP trunk on local extension then remote caller should drop the call. Don't "hook on" extension until PBX will show that call is disconnected (on status page). Then "hook on" extension.

Thanks

 

[worksighted]

I woudl recommend taking a waireshark capture. Once a call is established to 3CX, if the remote caller hands up, your provider shoudl send a SIp BYE to 3CX. If it does send a proper BYE then 3CX shoudl hang up. If it doesn't then 3CX doesnt know the call has ended.

Can you capture this?

Best,

Mike

 

[Ads]

Mike, Sy,

I took some wireshark traces as has been suggested and it appears we are not recieving BYE from our SIP provider all of the
time. Its strange in that we don't recieve BYE on connected calls longer than 30 secs or so. Our SIP provider Voiptalk.org
are looking into this and I will report back the final analysis.

Thanks for your suggestions.

Ads.

 

[Ads]

I've had a reply from my SIP trunk provider (Voiptalk) who have been able to replicate this problem on their 3CX test system and it appears have done some extensive testing and this is their response:

---------------------------------------------------------------

After detailed testing with some other PBXs and 3CX with or service and SIP trace analysis we found that problem is with 3CX with the way its handling incoming calls from our service.

Here is a detailed technical answer from one of our main SIP developer. This is of our test box and NB stands for NAT box (outbound proxy)

"The PBX registers with the
"sip:[email protected]:5060;rinstance=8411fec69e344bfb" contact , so the NB creates the "sip:[email protected]" virtual user for this contact.

But when receiving the INVITE from PSTN, the PBX does place in the replies a different contact: "sip:[email protected]:5060", so that the NB thinks it is about a different contact (end point) and creates a new temporary virtual user: "sip:[email protected]".

Because the call is linked to this temporary virtual user (which expires in 30 seconds as not related to an REGISTER), the BYE cannot be routed back at all.

The question is why the PBX uses a different contact during REGISTER and calls, even it is a single SIP entity ?
"
Please pass this to 3CX for their view.

-----------------------------------------------------------------------------

I get the gist of this but wondered if any of you guys with a better grasp of what this means could throw some light on whether or not this a SIP provider or 3CX issue etc.

Thanks,
Ads.