3300 30 seconds busy/reorder tone regardless of system timers

[GZgidnick]

Release level: 6.0 SP3
Active software load: 12.0.3.15

I cannot change the switch ringing timeout changing the timers.

I tried to increase/reduce the timers but the switch will ring 30 sec and timeout:
Call Forward No Answer Timer 5 / 50
Call Rerouting Timer 10 / 60

CCS Tracing is enabled for continuous output display
00:34:36 RIL DPN PEER AAPT-FQDN 7 26 ISRM_I
;10;*3#*19*Z#*58*Ca*1*Z#*100*0403971505#
00:34:36 RIL DPN PEER AAPT-FQDN 7 29 SSRM_C
*58*CW*PXP`_ONH@@DZYp#*50*0403971505#800
00:34:36 ROL DPN PEER AAPT-FQDN 7 27 NAM
*1#*50*800#*166*6#*100*r.technician*1#
00:35:06 RIL DPN PEER NIL_PEER_ 7 17 CRM/CIM ;2;*58*C2*G*400#*234*JP#

30 seconds exactly.

CRM/CIM Code:
2 Network termination
Used when the call is released by the network for any
reason (eg due to a timeout expiring, or service
interactions).

Call rerouting form is Normal for Always, Normal for First and Normal for Last Alternative respectively.
Call Forwarding Profile is clean for the extension (it happens with every extension though)

Reset the switch with Reset System.
Wall.

 

[wireman50]

Seen this wis SIP trunks where the peer profile has not been set up correctly

 

[GZgidnick]

I think you are right.

Tested with all my systems. Which are all deployed in the cloud and MPLS-ed off to the customers.
All my systems are with the same Carrier: AAPT

The failure is common across all the systems. 30 seconds cut-off.
Need to properly trace this down and see who is initiating the failure and analyze the SIP messages.

 

[Billz66]

do you have some sort of business continuity set at the carrier side
if so try disabling it , I have seen issues where that was taking the call away from the pabx

If I never did anything I'd never done before , I'd never do anything.....

and due to an endless stream of MiCollab , MiCC issues
Life would be simpler If only they tested products properly before releasing them .....

 

[GZgidnick]

Not aware of anything setup at carrier level, nonetheless I'll bring that point up. Thanks for that.

Once the analysis are complete, will post the results here.

 

[Billz66]

sip trace may be more helpfull than ccs trace as well

If I never did anything I'd never done before , I'd never do anything.....

and due to an endless stream of MiCollab , MiCC issues
Life would be simpler If only they tested products properly before releasing them .....

 

[GZgidnick]

SIP trace is necessary indeed.
Once I handle all the end-user feature issues I'll be posting here.

 

[Jemson]

Hi GZgidnick,

Did you get anywhere with this?

I am having the same issue with the same carrier in the same scenario, also tried 7.0 SP1 PR2. Proven across three different customers.
I completed a SIP trace, and sure enough get a CANCEL come in from AAPT at 30.000000.
Raised with AAPT, but they said "this is by design and can't be changed" Ie. Bad luck. (Wouldn't expect any more from their crappy support team).

I was hoping there would be an SDP option that I could toggle to send updates and potentially stave off the cancel request, but haven't managed to find anything that will work as yet.

 

[GZgidnick]

I tried to manipulate the SDP header with no luck.
Still haven't raised a case with AAPT due to lack of time and as the issue has still not been raised by my customer.
I will however very soon.

The answer you've got from the is not sufficient. There is no such protocol design that triggers disconnects after 30 sec ring time.
I'll try to look into this tomorrow if times allows and I'll keep you posted.