Call Forwarding Issue

lewiskeyte · ‎07-10-2016

Hi, I'm having a problem with call forwarding on a CME. Cleaned up config attached.

Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.4(3)M1, RELEASE SOFTWARE (fc1)

CME 10.5

Mix of SIP and SCCP phones

We have a main line, 2100, that is assigned to a single 7942. This forwards to a hunt group, 2998, for the office manager and receptionist. This seemed to be the easiest way to allow them to forward the main line to a mobile if the whole office will be out during the day.

ephone-dn 1 octo-line
 number 2100
 label Main Line
 description Main Line
 name Main Line
 call-forward busy 2998
 call-forward noan 2998 timeout 3

voice hunt-group 1 parallel
 final 2999
 list 2112,2113
 timeout 8 
 pilot 2998 
 description Ops 
!
!
voice hunt-group 2 parallel
 list 2110,2111,2112,2113,2114,2115,2116,2117,2118,2119,2120,2121
 pilot 2999 
 description Whole Office

When a call comes in via PRI to the main line, it forwards correctly to the hunt group. When a call comes in via PRI to someone's direct line, it rings twice and disconnects without forwarding. This occurs on both ephone-dn and voice register dn extensions.

Calls that come in from other CMEs via SIP trunk behave correctly for both the main line and the direct lines.

I'm not seeing anything obviously problematic in the debugs - I've looked at isdn q931, ccsip messages, and dial-peer. Let me know what other debugs would be useful to provide.

008842: Jul 11 02:20:18.355: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x3A99 
 Sending Complete 
 Bearer Capability i = 0x9090A3 
 Standard = CCITT 
 Transfer Capability = 3.1kHz Audio 
 Transfer Mode = Circuit 
 Transfer Rate = 64 kbit/s 
 Channel ID i = 0xA18389 
 Preferred, Channel 9 
 Progress Ind i = 0x8283 - Origination address is non-ISDN 
 Calling Party Number i = 0x0183, '006565719169' 
 Plan:ISDN, Type:Unknown 
 Called Party Number i = 0xC1, '80262112' 
 Plan:ISDN, Type:Subscriber(local)
008843: Jul 11 02:20:18.355: ISDN Se0/0/0:15 Q931: Received SETUP callref = 0xBA99 callID = 0x007A switch = primary-net5 interface = User 
008844: Jul 11 02:20:18.367: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xBA99 
 Channel ID i = 0xA98389 
 Exclusive, Channel 9
008845: Jul 11 02:20:18.415: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0xBA99
008846: Jul 11 02:20:26.423: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0xBA99 
 Cause i = 0x8090 - Normal call clearing
008847: Jul 11 02:20:26.667: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x3A99
008848: Jul 11 02:20:26.667: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xBA99

009745: Jul 11 02:47:16.147: //111667/9CA8CEA68081/SIP/Msg/ccsipDisplayMsg:
Sent: 
INVITE sip:2112@10.37.201.21:49184 SIP/2.0
Via: SIP/2.0/TCP 10.37.254.1:5060;branch=z9hG4bK12A815D8
Remote-Party-ID: <sip:006565719169@10.37.254.1>;party=calling;screen=yes;privacy=off
From: <sip:006565719169@10.37.254.1>;tag=9508C050-19E2
To: <sip:2112@10.37.201.21>
Date: Mon, 11 Jul 2016 02:47:16 GMT
Call-ID: 9CAB3FDF-464811E6-9EE4E1D5-FF1CB56F@10.37.254.1
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
Cisco-Guid: 2628308646-1179128294-2155968698-4192284032
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M1
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1468205236
Contact: <sip:006565719169@10.37.254.1:5060;transport=tcp>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 244

v=0
o=CiscoSystemsSIP-GW-UserAgent 2963 7474 IN IP4 10.37.254.1
s=SIP Call
c=IN IP4 10.37.254.1
t=0 0
m=audio 22530 RTP/AVP 0 101
c=IN IP4 10.37.254.1
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

009746: Jul 11 02:47:16.155: //111667/9CA8CEA68081/SIP/Msg/ccsipDisplayMsg:
Received: 
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.37.254.1:5060;branch=z9hG4bK12A815D8
From: <sip:006565719169@10.37.254.1>;tag=9508C050-19E2
To: <sip:2112@10.37.201.21>
Call-ID: 9CAB3FDF-464811E6-9EE4E1D5-FF1CB56F@10.37.254.1
Date: Mon, 11 Jul 2016 02:47:12 GMT
CSeq: 101 INVITE
Server: Cisco-CP7841/10.1.1
Contact: <sip:9CDC-2549@10.37.201.21:49184;transport=tcp>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Supported: replaces,join,sdp-anat,norefersub,resource-priority,ext
ended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-6.0.2,X-cisco-xsi-8.5.1
Allow-Events: kpml,dialog
Content-Length: 0

009747: Jul 11 02:47:16.223: //111667/9CA8CEA68081/SIP/Msg/ccsipDisplayMsg:
Received: 
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP 10.37.254.1:5060;branch=z9hG4bK12A815D8
From: <sip:006565719169@10.37.254.1>;tag=9508C050-19E2
To: <sip:2112@10.37.201.21>;tag=e0d173e589ee4ef778808037-678e1429
Call-ID: 9CAB3FDF-464811E6-9EE4E1D5-FF1CB56F@10.37.254.1
Date: Mon, 11 Jul 2016 02:47:12 GMT
CSeq: 101 INVITE
Server: Cisco-CP7841/10.1.1
Contact: <sip:9CDC-2549@10.37.201.21:49184;transport=tcp>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: "J" <sip:2112@10.37.254.1>;party=called;id-type=subscriber;privacy=off;screen=yes
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-6.0.2,X-cisco-xsi-8.5.1
Allow-Events: kpml,dialog
Content-Length: 0

009751: Jul 11 02:47:24.231: //111667/9CA8CEA68081/SIP/Msg/ccsipDisplayMsg:
Sent: 
CANCEL sip:2112@10.37.201.21:49184 SIP/2.0
Via: SIP/2.0/TCP 10.37.254.1:5060;branch=z9hG4bK12A815D8
From: <sip:006565719169@10.37.254.1>;tag=9508C050-19E2
To: <sip:2112@10.37.201.21>
Date: Mon, 11 Jul 2016 02:47:16 GMT
Call-ID: 9CAB3FDF-464811E6-9EE4E1D5-FF1CB56F@10.37.254.1
CSeq: 101 CANCEL
Max-Forwards: 70
Timestamp: 1468205244
Reason: Q.850;cause=16
Content-Length: 0

009752: Jul 11 02:47:24.235: //111667/9CA8CEA68081/SIP/Msg/ccsipDisplayMsg:
Received: 
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.37.254.1:5060;branch=z9hG4bK12A815D8
From: <sip:006565719169@10.37.254.1>;tag=9508C050-19E2
To: <sip:2112@10.37.201.21>;tag=e0d173e589ee4ef778808037-678e1429
Call-ID: 9CAB3FDF-464811E6-9EE4E1D5-FF1CB56F@10.37.254.1
Date: Mon, 11 Jul 2016 02:47:20 GMT
CSeq: 101 CANCEL
Server: Cisco-CP7841/10.1.1
Content-Length: 0

009753: Jul 11 02:47:24.243: //111667/9CA8CEA68081/SIP/Msg/ccsipDisplayMsg:
Received: 
SIP/2.0 487 Request Cancelled
Via: SIP/2.0/TCP 10.37.254.1:5060;branch=z9hG4bK12A815D8
From: <sip:006565719169@10.37.254.1>;tag=9508C050-19E2
To: <sip:2112@10.37.201.21>;tag=e0d173e589ee4ef778808037-678e1429
Call-ID: 9CAB3FDF-464811E6-9EE4E1D5-FF1CB56F@10.37.254.1
Date: Mon, 11 Jul 2016 02:47:20 GMT
CSeq: 101 INVITE
Server: Cisco-CP7841/10.1.1
Contact: <sip:9CDC-2549@10.37.201.21:49184;transport=tcp>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: "J" <sip:2112@10.37.254.1>;party=called;id-type=subscriber;privacy=off;screen=yes
Allow-Events: kpml,dialog
Content-Length: 0

009754: Jul 11 02:47:24.243: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent: 
ACK sip:2112@10.37.201.21:49184 SIP/2.0
Via: SIP/2.0/TCP 10.37.254.1:5060;branch=z9hG4bK12A815D8
From: <sip:006565719169@10.37.254.1>;tag=9508C050-19E2
To: <sip:2112@10.37.201.21>;tag=e0d173e589ee4ef778808037-678e1429
Date: Mon, 11 Jul 2016 02:47:16 GMT
Call-ID: 9CAB3FDF-464811E6-9EE4E1D5-FF1CB56F@10.37.254.1
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0

lewiskeyte · ‎07-10-2016

Noticed in a couple other call forwarding threads people were asking for debug voip ccapi inout, so have attached that as well for a failed call.

Ahmed Khalefa · ‎07-13-2016

Hello Lewiskeyte,

Did you find a solution for that ? ..

I revised your configurations and the debug outputs for both ccsip and voip inout .. and I have no clue why the CME sent a Disconnect message through the Q931 , or CANCEL message to 2112 ..

From the ccapi output , i can see the redirection to 2100 :

009873: Jul 11 04:49:37.735: //-1/xxxxxxxxxxxx/CCAPI/ccUpdateRedirectNumber:
type=6 Original Called Number=2112, Called Number=2112, Calling Number=006565719169, Calling DN=-1 Calling Id=112017,
Redirect Number=2100, Redirect Reason=2

but then a disconnect message with normal clearing :S

009910: Jul 11 04:49:37.735: //112018/AFCA37B88083/CCAPI/ccCallDisconnect:
Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)

normally for such cases , we should see an error like 302 Moved Temporarily .. or any message at least ...

one small notice .. i didn't find any inbound dial-peer for the PSTN .. like :

dial-peer voice xxx pots
incoming called-number .
direct-inward-dial

If you have an update , please keep posting on it ..

Thanks A lot,
Ahmed Salah

lewiskeyte · ‎07-13-2016

Hi Ahmed, no solution yet. I will try adding an incoming dial-peer and see if that helps.

As temporary fix, I've added the following rule so that calls to any DID go to the main line. All calls forward as expected with this in place, just like any call to the main phone number.

voice translation-rule 1
! 
voice translation-rule 2
 rule 1 /8026\(21..\)/ /2100/
!
!
voice translation-profile INCOMING_PSTN
 translate calling 1
 translate called 2
!
!
voice-port 0/0/0:15
 translation-profile incoming INCOMING_PSTN
 bearer-cap Speech

lewiskeyte · ‎07-13-2016

Hi, I've added an incoming dial peer but no luck.

dial-peer voice 12 pots
 description Inbound PSTN
 incoming called-number .
 direct-inward-dial

Are there any other debugs you'd like to see?

One thing that is different with this setup compared to others I've done - when someone calls out from their extension (to a mobile phone for example) the main line number is displayed, not their extension. I was thinking maybe the forward process passes a number to the IDSN that it doesn't accept, but if that was the issue I would think all forwards would fail, or we would get a different code. Just thought I'd mention this.

Ahmed Khalefa · ‎07-13-2016

Hi,
can you provide a "show call his voice brief" for a failed call ? ..
and for that specific ID , do "show call his voice id XXXX" , where XXXX is the output from the "show call his voic brief" on the top left ( 4 characters ) ..
for the other problem , this is related to your carrier ( PSTN ) may be it is expecting the correct type and plan .. as some carriers don't like the "unknown" to be sent ..
try to modify your Outgoing translation "OutgoingForwardExternal" , and you may do a specific one for testing with your mobile ..
like :

voice translation-rule 3000 rule 1 // // type any national plan any isdn

voice translation-rule 3001 rule 1 /^21..$/ /08026&/ type any national plan any isdn << i don't know the mobile numbering plan for this country

voice translation-profile Outgoing_NATIONAL_TEST 
translate calling 3001 
translate called 3000

lewiskeyte · ‎07-13-2016

Working on this - here are the debugs without this changed.

lewiskeyte · ‎07-13-2016

Have tried with this config - same behavior:

voice translation-rule 3000
 rule 1 // // type any national plan any isdn
!
voice translation-rule 3001
 rule 1 /^21..$/ /8026&/ type any national plan any isdn
!
!
voice translation-profile Outgoing_NATIONAL_TEST
 translate calling 3001
 translate called 3000
!
!
dial-peer voice 10 pots
 description Outbound PSTN
 translation-profile outgoing Outgoing_NATIONAL_TEST
 destination-pattern 8T
 port 0/0/0:15

Edit: Realized this was to fix the outgoing number issue. Don't have someone onsite at the moment to try calling out, will test tomorrow. My OutgoingForwardExternal rules were necessary to hairpin forward an external call to an external number. Might not be exactly correct but that's why I had the rule there. FYI the country is China in case it matters.

Ahmed Khalefa · ‎07-14-2016

just , make sure to change the number to your appropriate numbering plan :

voice translation-rule 3001
 rule 1 /^21..$/ /xx8026&/ type any national plan any isdn

or change it to international format :

voice translation-rule 3000
 rule 1 // // type any international plan any isdn

voice translation-rule 3001
 rule 1 /^21..$/ /868026&/ type any international plan any isdn

apply this to international dial-peer and test ...

Suresh Hudda · ‎07-10-2016

Configure below command under "voice service voip" and check once.

no supplementary-service sip moved-temporarily

Suresh

lewiskeyte · ‎07-10-2016

Hi, have just tried that, getting the same behavior.

lewiskeyte · ‎07-10-2016

In fact, entering that command appears to also break calls that come in from another CME, not just the PRI line.

Either way calling the main line works as expected.