Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

ICM Call Transfer Failing with Error 503

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:1001@10.1.1.100;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:2001@10.1.250.1>;tag=11E8C2C-11A
To: <sip:3100@10.1.1.10>;tag=ds9e058d56
Call-ID: 39D8BFBC-6B6611DF-8074A06E-F17D8643@10.1.250.1
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:2001@10.1.250.1: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:3100@10.1.1.10>;tag=ds9e058d56
From: <sip:2001@10.1.250.1>;tag=11E8C2C-11A
Call-ID: 39D8BFBC-6B6611DF-8074A06E-F17D8643@10.1.250.1
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:3100@10.1.1.10>;tag=ds9e058d56
From: <sip:2001@10.1.250.1>;tag=11E8C2C-11A
Call-ID: 39D8BFBC-6B6611DF-8074A06E-F17D8643@10.1.250.1
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:2001@10.1.250.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.10:5060;branch=z9hG4bKh.Dpvd3FJwRI4MnJsRCysw~~189
Max-Forwards: 70
To: <sip:2001@10.1.250.1>;tag=11E8C2C-11A
From: <sip:3100@10.1.1.10>;tag=ds9e058d56
Call-ID: 39D8BFBC-6B6611DF-8074A06E-F17D8643@10.1.250.1
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

4 REPLIES
Green

Re: ICM Call Transfer Failing with Error 503

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

Silver

Re: ICM Call Transfer Failing with Error 503

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

Green

ICM Call Transfer Failing with Error 503

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

Cisco Employee

ICM Call Transfer Failing with Error 503

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

5153
Views
0
Helpful
4
Replies