How to prevent CUBE from choosing a new outbound dialpeer upon REFER?

[Lando.Griffin]

Hi all, we have a CUBE that is choosing a new outbound dialpeer upon receiving a REFER. How can I get it to maintain its current connection? I've tried a few refer-related commands in the CUBE, hoping they would preserve the existing outbound connection, but no luck. 

Here is more detail:
We have a CUCM server, a voicemail server, and a CUBE. The CUBE has two outbound interfaces (I'll call them A and B). When a call is made to the voicemail system, it established a connection to the CUBE, and then the CUBE calls out through interface A. Once the call is established, the voicemail system then does a REFER to CUCM to make CUCM the new source for the call. But when CUBE receives the next packet from CUCM, rather than maintain the already established call path out interface A, the CUBE follows internal config logic and selects a new dialpeer out interface B. (I know this setup sounds crazy, I'm just simplyifing it for this post.)

Can anyone point me in the right direction to maintain the already established outbound dialpeer? Thanks.

[Celso Silva]

Do you have configured huntstop under your dial-peers? Have you tried that?

There is a huntstop command under voice class server-group - if you are using that - that can be used with resp-code but I think REFER is under 100. So I'm not sure if that is applicable and if that would work for your use case.

[Lando.Griffin]

Hmm, I wish I knew more in order to provide a better response, but here is a sample of what the CUBE is receiving from CUCM. As you can see, it is a 101 INVITE which contains a REFERRED-BY header (the shown IP is the voicemail system), and it also contains a REPLACES header, which refers to the conversation already established by the voicemail system. 

User-Agent: Cisco-CUCM14.0
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Referred-By: <sip:4198881234@10.18.160.19>
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Call-Info: <sip:10.18.160.3:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=VIDEO_UNSPECIFIED
Session-ID: 7b54b011ca4513d21f1481d868c36ba0;remote=00000000000000000000000000000000
Cisco-Guid: 3166060800-000536-0002-0060002
Session-Expires: 1800
P-Asserted-Identity: <sip:9378884569@10.18.160.3>
Remote-Party-ID: <sip:9378884569@10.18.160.3>;party=calling;screen=yes;privacy=off
Contact: <sip:9378884569@10.18.160.3:5060;transport=tcp>
Max-Forwards: 70
Replaces: T.EwSR-Hpop9oin4eGCFEcLHnwMGTP4J;to-tag=27E1BF61-1E60;from-tag=5xOR6iqaylmyS0jGXVuoTyhGcTeJX6yg
Content-Length: 0

[b.winter]

It would make more sense to deliver the debug of a complete call and the complete config (without any data like user, pwd, secret), instead of throwing pieces of information around you.

debug ccsip messages
debug voice ccapi ind 1
debug voice ccapi ind 2
debug voice ccapi ind 74

[Roger Kallberg]

Maybe the section about refer in this document could be helpful or at least give you an idea on what to do. Direct Routing for Microsoft Phone System with Cisco Unified Border Element (CUBE) 

[Lando.Griffin · Accepted solution]

It looks like I was able to resolve this issue with the command:
sip-ua
   handle-replaces

Apparently this command is disabled by default, and by adding it, it allows the CUBE to handle the SIP Replaces header in incoming calls. Now, instead of treating the incoming INVITE packet containing a Replaces header like a new call, it appears to be maintaining the existing outbound call leg, only replacing the inbound info. Appears to be, anyway, from what I can tell from the logs. 

Thanks, everyone, for your responses.