ICM Call Transfer Failing with Error 503

Unanswered Question
May 30th, 2010
User Badges:

I have a CVP call flow that is failing with a 503 Service Unaviable message from UCM. I would appreciate any thoughts you might have.


  1. The call arrives at the ingress gateway
  2. The Ingress gateway sends the call to CVP which sends it to ICM
  3. ICM runs a script and generates a label (verified)
  4. The label goes to CVP which hits a static route to the UCM where the agent phone is (no SIP Proxy)
  5. The CVP sends an INVITE to the UCM and I see it arrive on the SIP Trunk by looking at the trace output on UCM
  6. The UCM then sends a 503
  7. The 91919191 ringtone is breifly played before the call is disconnected.


The following is present:


  • SIP Trunk to UCM set to OnNet and with correct Partition and CSS settings
  • SIP Trunk to CVP set to OnNet and with correct Partition and CSS settings
  • Calls can be setup in both directions across the SIP Trunk from UCM to GW
  • Inbound calls to the SIP Trunk between UCM and CVP seem to be where I get the 503 messages (from UCM)
  • 10.1.1.100 is the UCM
  • 10.1.1.10 is the CVP
  • 10.1.250.1 is the Gateway


Here is the CVP error log


1198: 10.1.1.10: May 30 2010 13:56:36.581 -0700: %CVP_8_0_SIP-3-SIP_CALL_ERROR:  CALLGUID = EB0005611000012863D838210A01010A LEGID = EB0005611000012863D838210A01010A-127525299653448 - [OUTBOUND] - DsSipInvitation - <sip:[email protected];transport=udp>;tag=1885211893 - 1 REJECTED WITH 503 - Service Unavailable Warning: 399 CUCM "Unable to find a device handler for the request received on port 5060 from 10.1.1.10"  [id:5004]


1213: 10.1.1.10: May 30 2010 13:56:38.581 -0700: %CVP_8_0_SIP-3-SIP_CALL_ERROR:  CALLGUID = EB0005611000012863D838210A01010A LEGID = 37CA21A6-6B6511DF-8065A06E-F17D8643 - [INBOUND] - ABNORMALLY ENDING - SIP code [503], Reason Hdr [SIP;cause=503] Service Unavailable, GW call using SURV TCL flag [false], NON NORMAL flag [true], USE ERROR REFER flag [true] with AGE (msecs) 31828 and Call History : 811111111127|-1;1001|1; [id:5004]


1220: 10.1.1.10: May 30 2010 13:56:38.675 -0700: %CVP_8_0_SIP-3-SIP_CALL_ERROR:  CALLGUID = EB0005611000012863D838210A01010A LEGID = 37CA21A6-6B6511DF-8065A06E-F17D8643 - [INBOUND]: Refer failed with 503 - Service Unavailable. May be a problem with Routing Configuration or Gateway Dial-Peer. [id:5004]


1222: 10.1.1.10: May 30 2010 13:56:38.675 -0700: %CVP_8_0_SIP-3-SIP_CALL_ERROR:  CALLGUID = EB0005611000012863D838210A01010A LEGID = 37CA21A6-6B6511DF-8065A06E-F17D8643 - [INBOUND] - ABNORMALLY ENDING - SIP code [503], Reason Hdr [SIP;cause=503] Service Unavailable, GW call using SURV TCL flag [false], NON NORMAL flag [true], USE ERROR REFER flag [true] with AGE (msecs) 31922 and Call History : 811111111127|-1;1001|1; [id:5004]


Debug ccsip messages on the gateway


May 30 14:08:09.830: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
NOTIFY sip:10.1.1.10:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.1.250.1:5060;branch=z9hG4bK1E1E7D
From: <sip:[email protected]>;tag=11E8C2C-11A
To: <sip:[email protected]>;tag=ds9e058d56
Call-ID: [email protected]
CSeq: 103 NOTIFY
Max-Forwards: 70
Date: Sun, 30 May 2010 21:08:09 GMT
User-Agent: Cisco-SIPGateway/IOS-12.x
Event: refer
Subscription-State: terminated;reason=noresource
Contact: <sip:[email protected]:5060>
Content-Type: message/sipfrag
Content-Length: 35


SIP/2.0 503 Service Unavailable



May 30 14:08:09.834: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 10.1.250.1:5060;branch=z9hG4bK1D695
To: <sip:[email protected]>;tag=ds9e058d56
From: <sip:[email protected]>;tag=11E8C2C-11A
Call-ID: [email protected]
CSeq: 102 NOTIFY
Content-Length: 0
Allow-Events: refer
Allow-Events: kpml
Allow-Events: cvp-transfer



May 30 14:08:09.834: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 10.1.250.1:5060;branch=z9hG4bK1E1E7D
To: <sip:[email protected]>;tag=ds9e058d56
From: <sip:[email protected]>;tag=11E8C2C-11A
Call-ID: [email protected]
CSeq: 103 NOTIFY
Content-Length: 0
Allow-Events: refer
Allow-Events: kpml
Allow-Events: cvp-transfer



May 30 14:08:09.838: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.10:5060;branch=z9hG4bKh.Dpvd3FJwRI4MnJsRCysw~~189
Max-Forwards: 70
To: <sip:[email protected]>;tag=11E8C2C-11A
From: <sip:[email protected]>;tag=ds9e058d56
Call-ID: [email protected]
CSeq: 3 BYE
Content-Length: 35
Contact: <sip:10.1.1.10:5060;transport=udp>
Reason: SIP;cause=503
Content-Type: application/gtd


REL,
PRN,isdn*,,NI***,
UUS,


Trace on the UCM


000029127| 2010/05/30 14:08:07.776| 001| SdlSig    | UdpDataInd  | wait | SIPUdp(1,100,55,1) | EnvProcessUdpPort(1,100,213,1)  | (1,100,213,1).54-(*:*)  | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0] varStatus=0 varId=0 varSrcIpAddr=167837962 varIpPort=29532 varFamily=2


000029128| 2010/05/30 14:08:07.812| 001| SdlSig    | SIPSetupInd | wait | SIPStationInit(1,100,57,1) | SIPHandler(1,100,63,1) | (1,100,213,1).54-(*:10.1.1.10) | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0] SignalInfo= SIPInviteSdp CcbId= 29 --TransType=2 --TransSecurity=0 PeerAddr = 10.1.1.10:29532 IdParse= 1 callingNum= 2001 callingName=  calledNum= 1001


000029129| 2010/05/30 14:08:07.812| 001| SdlSig    | UdpSendReq  | start | EnvProcessUdpPort(1,100,213,1)  | SIPUdp(1,100,55,1) | (1,100,213,1).54-(*:10.1.1.10) | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0] varId=0 varIpAddr=167837962 varIpPort=5060 varFamily=2


000029130| 2010/05/30 14:08:07.813| 001| SdlSig    | SIPDisconnReq | wait | SIPHandler(1,100,63,1) | SIPStationInit(1,100,57,1) | (1,100,213,1).54-(*:10.1.1.10) | [T:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0] CcbId= 29 --TransType=2 --TransSecurity=0 PeerAddr = 10.1.1.10:5060 ccCause= 0 sip_disc_cause= 503


000029131| 2010/05/30 14:08:07.814| 001| SdlSig    | UdpSendReq  | start | EnvProcessUdpPort(1,100,213,1)  | SIPUdp(1,100,55,1) | (1,100,213,1).54-(*:10.1.1.10) | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0] varId=0 varIpAddr=167837962 varIpPort=5060 varFamily=2

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.

8jdemeule wrote:


I have a CVP call flow that is failing with a 503 Service Unaviable message from UCM. I would appreciate any thoughts you might have.


  1. The call arrives at the ingress gateway
  2. The Ingress gateway sends the call to CVP which sends it to ICM
  3. ICM runs a script and generates a label (verified)
  4. The label goes to CVP which hits a static route to the UCM where the agent phone is (no SIP Proxy)
  5. The CVP sends an INVITE to the UCM and I see it arrive on the SIP Trunk by looking at the trace output on UCM
  6. The UCM then sends a 503
  7. The 91919191 ringtone is breifly played before the call is disconnected.


Perhaps you have omitted some steps for clarity. Allow me to expand 3-4.


1. Call arrives at the ingress gateway

2. Gateway sends the call to CVP which sends it to ICM.

3. ICM runs a script and the first node is "Send To VRU".

4. ICM pauses the script there, and the label on the NVRU for the routing client is returned.

5. CVP has "Send to Originator" so sends the label back to the ingress gateway.

6. The voip dialpeer on the VRU label runs the bootstrap service and CVP contacts ICM again passing the correlation ID

7. ICM finds the paused script and restarts it.

8. ICM generates a label (verified)


But this is by far the simplest CVP and should work. I usually start with something simple like this, before moving on to queue to skill groups etc.


The ICM script will have Start -> Send To VRU -> Label. The label will be the extension of the agent phone on the CVP routing client. CVP has a static route to CUCM, as you say.


In order for this to work you only need one SIP trunk - from CUCM to CVP for the signaling. Ignore the trunk from CUCM to the GWY. You don't need it - delete it for clarity.


The fact is, CUCM is rejecting the INVITE. You know that. Is the device pool of the trunk compatible with the device pool of the target?


Regards,

Geoff

Abu Hadee Tue, 06/01/2010 - 05:36
User Badges:
  • Silver, 250 points or more

Hi


Looking at the cucm logs, PeerAddr = 10.1.1.10:5060 ccCause= 0 sip_disc_cause= 503


The call is disconnected due to device not present in CUCM.


I'm not clear about your description of call flow and what logs shows.


Are you using refer to transfer the call to CUCM? Because looking at the gw debug, gw is notifying the cvp about 503 rejection.


Can you collect the complete log from cucm gw, and if possible packet capture from the cvp. Its not css or partion issue. Because you would different error


Thanks

- abu

I was bringing up a new CVP 8.5 in my lab and had a simple script that did a "Send To VRU", played a bit of music, and released the call. Send to Originator engaged on the NVRU label and the ringback label. Works fine.


Then I changed the script to not release the call but to return the label of a device target of a phone I configured.


Static route in the Outbound Proxy to CUCM. SIP Trunk created to the Proxy in all Default device pools.


Pretty simple.


I heard a brief ringback and then technical difficulties. The error was the above "Unable to find a device handler". Everything looked like it was created correctly, but it did not work.


I had forgotten to set DTMF Signaling Method to RFC 2833.


Regards,

Geoff

Senthil Kumar Sankar Tue, 05/08/2012 - 16:25
User Badges:
  • Cisco Employee,

Hi


By looking the error "Unable to find a device handler" what i believe is your CUCM IP address which is in the CVP Static Route is not listed in the CallManagerGroup which is assigned to your SIP Trunk's Device Pool.


What is the CUCM Version you use. If you are using 8.5 and above you can use the below feature


SIP Trunks Can Run on All Active Unified CM Nodes


When the Run on all Active Unified CM Nodes option is checked on a SIP trunk, Unified CM creates

an instance of the SIP trunk daemon on every call processing subscriber within the cluster, thus allowing

SIP trunk calls to be made or received on any call processing subscriber. (Prior to this feature, up to three

nodes could be selected per trunk by using Unified CM Groups.) With Run on all Active Unified CM

Nodes enabled, outbound SIP trunk calls originate from the same node on which the inbound call (for

example, from a phone or trunk) is received. As with all Unified CM SIP trunks, the SIP daemons

associated with the trunk will accept inbound calls only from end systems with IP addresses that are

defined in the trunk's destination address fields. Running SIP trunks on all nodes is recommended where

the SIP trunk is required to process a large number of calls so that outbound and inbound call distribution

can be evenly spread across all call processing subscribers within a cluster. Also, when multiple SIP

trunks to the same destination(s) are using the same subscriber, a unique incoming and destination port

number must be defined per trunk to allow each trunk to be identified uniquely.


Regards,

Senthil

Actions

This Discussion