Unable to forward calls coming through SIP trunk

[gayathridissanayaka]

Hi I am using a Applianx gateway to interface a CUCM and a Nortel Meridian PBX. My issue is that I need to keep calls ringing for at-least 30 mins, if no one answers the call.Because of the RNA timer in the Line group we can only go up to 180 seconds of ringing without any call forwarding.

The calls that I'm talking about first hit a hunt pilot-->hunt list--> line group--> SIP device lines, and in order to forward the call back to these devices I have to forward them back to the same hunt pilot or I can also create another hunt pilot-->same hunt list-->same line group-->same device lines, and then forward the calls to this second hunt pilot and then within the second hunt pilot settings forward the calls to the first hunt pilot, so the call will keep on ringing until answered. This works fine for IP to IP calls(devices that are registered with CUCM) , but when trying to forward a call that is coming through the SIP trunk, the call stops ringing at 3 mins. Has anyone experienced this issue? Any suggestions would be appreciated. 

I have attached the SDL real time traces and also have attached the two subscriber logs and one publisher logs, if any one would like to see. Could this be a timer that is causing the issue. In addition I have also attached the gateway logs and the SIp logs from the gateway.Please look towards the end of the traces for this issue. Please let me know if anyone could find a reason why.. Thank you very much.

192.168.10.4-Applianx gateway IP

192.168.10.7-publisher

192.168.10.9-subscriber 1

192.168.10.8-subscriber 2

2212-extension registered to Meridian PBX

404921-Huntpilot that the 2212 hits

500000-seconds hunt pilot 2212 hits

4922,4901 the lines of the IP phones that this call was receiving.

[Wilson Samuel]

Hi Gayathri,

You may want to change the Line Parameter at the "No Answer Ring Duration (seconds)" and increase it to 900,000 msecs.

Also, the Service Parameter for this is set by the T301 Timer which by default is 180,000 msec = 180 seconds = 3 mins

You may increase the timer at the max as 900,000 msesc = 900 Seconds = 15 mins. That is the hard core limit

(and I doubt you can do CFWD from one HP to next Hunt Pilot / Line Group would make it any longer than 15 mins possible because the system may detect it as Loop, and kick in the Loop prevention mechanism and drop the call, however no harm in trying)

T301 Timer:	This parameter specifies a timer for receiving the Alerting message. For exact timer definitions, refer to the Q.931 specification. The timer stops when the Connect message is received. Ensure that this value is always greater than the value that is specified in the Forward No Answer Timer parameter and Auto Answer Timer parameter; if it is not greater, the call does not get forwarded or auto-answered and the caller receives a busy signal.
	This is a required field.
	Default:  180000
	Minimum:  36000
	Maximum:  900000
	Unit: msec

[gayathridissanayaka]

Hi Samuel,

The maximun you can go for for No Answer ring duration on the Service paramerers is 300 seconds and on the Line group the maximum is 180 seconds. Also as I have already set the T301 timer to 900000ms. Any IP device registered with CUCM can ring the hunt pilot and the forwarding is working fine and these calls continue till 30 mins then drop off. it is the calls that are coming through the gateway experiencing this issue.   Thanks

[Wilson Samuel]

Interesting scenario. I will try to simulate the same in my lab and let you know if I am able to make any changes

Tnx

[gayathridissanayaka]

Hi,

Do we need a license on a CUCM registered SIP trunk. I'm just wondering if there is a license requirement that is limiting the incoming ringing on the SIP trunk to 180 seconds.

Thanks

G

[Mohammed al Baqari]

Hi,

I will lab this today and will get back to you by tomorrow morning. But I am not aware about any license for this.

[Mohammed al Baqari]

Hi,

I just tested it and got disconnected after 3 mins. But from the session trace, the disconnect is coming from my telco rather than CUCM which I understand that telco won't keep the channel occupied for long time. See below session trace.

Can you generate similar one from your cluster.

[gayathridissanayaka]

Hi Mohammed,

I did further testing and below is a SIP message diagram that I could generate from CUCM. To me it looks like the gateway which is 1923168.10.3 is sending a CANCEL request exactly same as your message number 7 in your diagram. Please confirm if I am right. The time that the call starts as per my diagram is 08.02.59.912, and the call should be forwarded to the next hunt pilot at 120 seconds which is at 08.04.59.965 , then the call drops at 08.05.59.918 due to a CANCEL request sent by the gateway.

Is this behavior similar to yours? I have attached the diagram you requested here if you want to check please. 

regards,

Gayathri

[Mohammed al Baqari · Accepted solution]

Hi,

That is right.

From the diagram which you attached there are two signaling paths:

1. The subscriber (192.168.10.9) is signaling the phone (192.168.30.21) for calls 1 (red color) then call 2 (green color) then call 3 (purple color).

2. The Cancel request is coming for the Applianx Gateway (blue color) which is similar to my case (the voice gateway). Based on this cancel request, CUCM stops signaling the phones.

Summary: You need to tune the timer on the applianx gateway. In my case my telco was canceling the call.

[gayathridissanayaka]

Thanks for the confirmation Mohammed. Much appreciated. 

[gayathridissanayaka]

Hello everyone,

A quick update. After been in contact with the applianx , they have found that one of the SIP timers expires at 180 seconds, and it is not visible to the user to change, in other words, it is a feature that needs developed and added to the firmware of the gateway. 

Thanks everyone for your support comments. 

[Mohammed al Baqari]

Great to identify the root cause as this was confusing everyone. 

Please mark the question as answered and remember to rate useful posts 

[Vivek Batra]

I think you had this discussion before too. Still wondering the real use case to ring the called phone for 30 minutes. Who is the caller who can lift the handset and wait for 30 minutes to get call answered? Can you please elaborate the real use case?

[gayathridissanayaka]

Hi Vivek,

Yes after that discussion managed to get the calls forwarded within the SIP devices registered to the CUCM. Now any calls coming through the SIP trunk would not ring more than 3 mins. 

The reason to have unanswered calls to ring for atleast 30 mins is that this network is a safety critical comms network, therefore we need to make sure someone answers the call somehow thus atleast 30 mins incoming. THanks

Gayathri

[avinsrid89 · Accepted solution]

Hi,

The issue is on Applianx here. They are unable to handle the UPDATE sent by CUCM when the call is redirected to second hunt pilot (500000) after RNA timeout on first hunt pilot.

The update is sent by CUCM to the Applianx to inform that the Remote Party ID is now 500000. However, Applianx seems to not be able to handle this and throws a 500 Internal Server error.

Incoming CALL ID from Applianx: Call-ID: 01630800-00000964-55BB8D94-00000005@192.168.10.4

Here is where we fire the RNA on hunt pilot 1: 

05753520.000 |15:02:36.994 |SdlSig   |RNAReversionResTimer                   |call_alerting                  |HuntListCdrc(3,100,181,454)      |SdlTimerService(3,100,3,1)       |3,100,13,793.2^192.168.10.4^*            |[R:H-H:0,N:0,L:0,V:0,Z:0,D:0] 

05753520.001 |15:02:36.994 |AppInfo  |Jijo Hunt list cdrc RNA = 1

We then reject this call with cause code 19 (expected):

05753564.000 |15:02:37.005 |SdlSig   |CcRejInd                               |wait                           |Cc(3,100,213,1)                  |HuntListCdrc(3,100,181,454)      |3,100,13,788.21^192.168.30.21^*          |[R:N-H:0,N:2,L:0,V:0,Z:0,D:0] CI=58315231 CI.branch=0  c.l=1 c.cid=8 c.cs=0 c.lc=0 c.r=0 CV=19 rejectType=1 dtmDisconn=F FDataType=0opId=0ssType=0 SsKey=0invokeId=0resultExp=Fbpda=FTransparentData=null CanSupportSIPTandN=false TransId=0 AllowBitMask=0x0 UserAgentOrServer= OrigDDName=locale: 1 Name:  UnicodeName:  pi: 0 mCallerId= mCallerName= mediaCause=0

Now, we forward call to next hunt pilot:

05753572.008 |15:02:37.006 |AppInfo  |Forwarding - initiateCFNA - CFNA, callKey= 0x21

05753611.001 |15:02:37.007 |AppInfo  |RouteListControl::idle_CcSetupReq - RouteList(HL_SOUTH2), numberSetup=0 numberMember=4 vmEnabled=0

This causes UPDATE to be triggered to Applianx with new remote party id:

05753705.001 |15:02:37.069 |AppInfo  |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 192.168.10.4 on port 5060 index 11930 
[531520,NET]
UPDATE sip:2212@192.168.10.4;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.10.9:5060;branch=z9hG4bKd2d84e5e131c
From: 2212 <sip:2212@192.168.10.9>;tag=213432~946f5a50-7410-423d-a5bb-36fb6cd3f0d0-58315230
To: 2212 <sip:2212@192.168.10.4>;tag=ACU-2a008531-151e018c
Date: Fri, 31 Jul 2015 15:00:36 GMT
Call-ID: 01630800-00000964-55BB8D94-00000005@192.168.10.4
User-Agent: Cisco-CUCM9.1
Max-Forwards: 70
Supported: timer,resource-priority,replaces
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 UPDATE
Supported: X-cisco-srtp-fallback
Supported: Geolocation
P-Asserted-Identity: <sip:500000@192.168.10.9>
Remote-Party-ID: <sip:500000@192.168.10.9>;party=calling;screen=yes;privacy=off
Contact: <sip:8c3deb6d-a503-8513-4601-7d77a85ce60b@192.168.10.9:5060;transport=tcp>
Content-Length: 0
 

But Applianx does not like this and throws 500 Internal Server Error which is not right. They should acknowledge this message in the middle of a RINGING phase:

05753708.002 |15:02:37.072 |AppInfo  |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 192.168.10.4 on port 5060 index 11930 with 395 bytes:
[531521,NET]
SIP/2.0 500 Internal Server Error
Via: SIP/2.0/TCP 192.168.10.9:5060;branch=z9hG4bKd2d84e5e131c
From: 2212 <sip:2212@192.168.10.9>;tag=213432~946f5a50-7410-423d-a5bb-36fb6cd3f0d0-58315230
To: 2212 <sip:2212@192.168.10.4>;tag=ACU-2a008531-151e018c
Call-ID: 01630800-00000964-55BB8D94-00000005@192.168.10.4
CSeq: 101 UPDATE
Content-Length: 0
Retry-After: 9
User-Agent: ApplianX-Gateway

This is trigger for entire issue.

~Avinash