Hairpin call transfer on CME

I am trying to setup a Cisco 2811 with CME 4.0 to perform hairpin call transfers, specifically to my CUE module installed in the router. As I understand it this will allow the call to be transported through the CME to the CUE by concatenating the 2 SIP links (between SP - CME and CME - CUE) together so that a redirect SIP message isn''t sent to the SP to call the CUE SIP device directly. As the CUE is on a private network this isn't possible.

I have read some info on this and have done the following

explicitly disable H450.2 and H450.3 and enabled H450.12

However i haven't found an answer on how to force the hairpin routing.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

CME 4.0 is very old.
Yes, you need to concatenate 2 independent SIP calls as other endpints cannot chat directly.
Are the cme and the cue already have the ability to connect calls between them?
Is a sip VPN channel from the 2811 other wan ip to the cue a possible consideration that was rejected based on your comment?

Do you want all calls to pass through the cme on their way to the cue ?

As gheist pointed out cme is up to version 9.
What version is your cue?

Presumably you are out of TAC support?
ElvorfinAuthor Commented:
I'm aware that CME 4.0, and I do have a router that is running CME8 but my CUE is running 3.2.3 which isn't compatible with post CME7.0 due to the licensing changes that were implemented after CME 7.
To answer your question Arnold, internal connections between CME and CUE appear to be working fine, it's just when calls are coming from my external SIP provider.

However, I have found a partial solution to the problem, using the command :-
no supplementary-service sip moved-temporarily

This stopped the "Contact" parameter being sent to my SIP provider so the SIP trunks were concatenated, and external callers received the voicemail greeting.

Unfortunately this has highlighted an additional problem. CUE is not recording the message from the caller. I assume that this is a problem with routing the actual voice traffic (RTP protocol ?) to the CUE which is on a local private address. Is there something else that i need to do in the SIP setup to get the RTP traffic to route through the CME.

Oh, I should add that the dial-peer pointing to the CUE has "no vad" set.

The IT Degree for Career Advancement

Earn your B.S. in Network Operations and Security and become a network and IT security expert. This WGU degree program curriculum was designed with tech-savvy, self-motivated students in mind – allowing you to use your technical expertise, to address real-world business problems.

Do you have an unused/available DID on the CME that can be configured to forward to the cue.

depending on how the call gets to the CUE, it sounds as though the issue deals with the multiple forwards.

Can a call be answered on a phone.

If you have access to TAC, seeing whether a dial-peer/sip trunk can be setup between the cme and cue with the passing if call versus forwarding the call would then allow the call to go into voicemail.

I might be misinterpreting your setup/call flow.
ElvorfinAuthor Commented:

Yes I have a spare DID that I have already configured for external access into the voicemail system. That appears to work as I can dial into the voicemail and get the response "enter your user ID" from where i can access user mailbox and GDMs

Voice calls to internal extensions from PSTN calls on the SIP trunk work just fine. It may however be worth noting that the IP phones are running SCCP not SIP.

I'm afraid I don't have access to TAC, but i don't really understand what you mean by "passing of calls rather versus forwarding"

Not sure if this helps with your understanding of how calls get to the CUE but the basic setup is a 2811 router with a ADSL connection, and an internal AIM-CUE. IP phones are connected to fa0/0 on a subnet with the AIM-CUE service module also on this subnet.
See if this discussion is similar to your situation and what you are experiencing.
ElvorfinAuthor Commented:
Hi. It is quite a similar issue, though I'm actually getting through to my voicemail system now from an external dial in, what i'm missing now is CUE recording messaged from an external caller.

I'm pretty sure it's something to do with routing of RTP traffic, but i don't know what, given that voice calls are fine to extensions registered with the CME which are on the same subnet as the CUE. But maybe I'm wrong.
If the external caller hitting the cme is then forwarded to the cue and the call is answered everything is fine, the voicemail part in this scenario, will be seen as yet another forward which will encounter the issue.

The discussion includes some debug testing to confirm that the outflow of the cue end up being sent back to the cme versus being router differently.
ElvorfinAuthor Commented:
I'm not sure i understand that 100% If the Caller is forwarded to the CUE, which then answers the call by playing the mailbox greeting, hasn't the call already been forwarded to voicemail? Are you saying the audio sent by the caller after the mailbox greeting is another call transfer?

Is this why you think it may be a call transfer limitation?

I will run through the suggested debug when I can later today, as I don't have direct access. I will post it once I have it.
ElvorfinAuthor Commented:
I've attached the sanitised output of debug voice ccapi inout as requested.

From what i can see is an incoming call being answered and after 10 secs being redirected to 8888, my voicemail pilot number. Interestingly there was no additional debug output whilst the voicemail greeting was being played or whilst i was leaving a message. The final messages were when i hung up.

Does the debug provide you with any additional ideas?

Whilst I was thnking about routing i realised the the CUE could not see my VOIP service provider as the service module wasn't NATing to the ADSL interface. I added that and restarted the CUE. But no change.
I think that just confirms that your config is a forward forward to VM (no answer, busy)

Try the same log on the DID that forwards to an extension that when not answered is forwarded to the auto-pilot.  

I think your question deals with actually having the CME merely channel the incoming calls directly to the CUE functioning as a proxy router.

I think that is the hair pinning you are looking for.

Let me see if I can get to a closer example from Cisco.

I think they often have common configuration examples based on a criteria set.
ElvorfinAuthor Commented:
Arnold, yes the three extensions that the DID numbers ring should all forward to VM if unanswered or are busy. I want these extensions to ring first and then for CME to forward them to CME if unanswered (for whatever reason). I have sussed out how to do that by disabling the moved temporarily option from SIP.

My initial question has moved on from there I believe to one of why the SIP traffic is being forwarded to CUE, and it serving the requests and playing greeting messages etc, but CUE not recording the audio conversation between caller and mailbox which I assume to be the same a the audio conversation between IP phone and IP phone.

I appreciate you looking for a similar scenario from Cisco. I've sometimes found it difficult finding config examples the same as my issue. I have to say i'd done a great deal of reading on Cisco trying to get my CME and CUE to talk to each other for external calls as their configuration examples matched my config, but it wasn't always entirely clear whether their scenario was the same as mine. A lot of the "external" calls that they discuss are coming form CMEs based in other offices and not form SIP service providers.
I understand, I think the issue is as you point out that when you have a direct DID to the CUE Pilot, you can interact CME forward to pilot extention CUE.
The issue I think with the CME to Phone Extension To Cue into Voicemail is the too many forwards.
Is the following what your setup is

SIP Provider <=> 2811 <=> Phones
                                   \=> CUE server


SIP Provider <=> 2811 <=> CUE server <=> Phones
ElvorfinAuthor Commented:
It's the former arnold. All calls come through the CME and the phones are "attached" via a switch to fa0/0, the AIM-CUE module lives in the 2811.

Do you think that it's a call forward limit that I am exceeding?
In this case I do not think it is a forwarding issue, can you double check whether the extension have mailboxes setup for each extension.
Can internal calls to the individual phone extension, go into voicemail and leave a message without an issue?
 Do you have web access to the CUE interface?

Is the issue you have deals with an external call going to the auto attendant that transfers the call to the phone and then goes to the CUE for voicemail?
ElvorfinAuthor Commented:
I have three mailboxes on the CUE, one is a personal mailbox and two are GDM mailboxes DN 3774 goes to a personal, and 2884, 2885 go to GDM mailboxes, they are all setup with a local and E.164 numbers.

Internal calls can leave messages on the CUE, and i can see the mailbox stats increment on the CUE CLI

I do have web access to the CUE, though only on the private network not to the internet. However, i can RDP to a 2008 server in  the network to get to it.

No I haven't configured AA, inbound DID calls go directly to the DNs and then get forwarded to 8888 (voicemail pilot number) on noan or busy.

I'm getting slightly annoyed with this setup as it seems to have been one hurdle after another and now that I am so close ....... aaarrrggghhhhh!
I know what you mean, but ...

Does one work while others do not or non work?
debugging the cue while an external call is being made into an extension that is allowed to fall through and enter the cue.  It could be something simple.
What format does the CME use for external calls to the phones?

See if the example for sip and other configuration matches yours
ElvorfinAuthor Commented:
Sadly none of them work, which I guess is a good thing so at least I know they all have the same issue. I'll check the codec of inbound calls but pretty sure it's G711

I'll have a look at those articles and get back to you. Thanks.
ElvorfinAuthor Commented:
Having read the article now, i think that this example is more about someone manually transferring a call directly to another persons voicemail. I don't think that it's relevant to my issue of no audio being recorded.

I'll have a go at debugging the CUE later.
The part of interest in the last example deals with making sure you have a dial-peer between cme and cue.
Actually I think the situation you have could be close enough.
External call to an extension answered and then forwarded to another extension that does not pickup and no answer/busy to voicemail. Does the cue behave the same for an external call or it works meaning the voicemail is recorded/stored)?
ElvorfinAuthor Commented:
I have a dial-peer configured from the CME to CUE which is

dial-peer voice 8888 voip
 description Voicemail
 destination-pattern 8888
 session protocol sipv2
 session target ipv4:
 dtmf-relay sip-notify
 codec g711ulaw
 no vad

<quote> External call to an extension answered and then forwarded to another extension that does not pickup and no answer/busy to voicemail. </quote>

Not quite, incoming callis not answered, it is ringing an unanswered extension which then redirects to 8888 (voicemail pilot number).

For external call voicemail answers, plays mailbox greeting but doesn't record message.
For internal call voicemail answers, plays mailbox greeting and does record message.

It's the former that I'm having issues with.
I am trying to see whether the external to an answered extension which then forwards to another extension that is not picked up goes to voicemail, plays the greeting
In this case is the voicemail recorded or not?

Trying to see whether any externally originating call hitting the cue (on the first extension noans attempt or being forwarded from another extension) runs into the same issue of not recording.
Presumably internal calls forwarded and direct have their voicemail saved.
ElvorfinAuthor Commented:
Ah OK I see what you are saying. I might be able to give that a try....

OK so i setup one DID extension to redirect to 2884 (internal extension of DID) on no answer and then set that to redirect to VM on no answer. Call transferred between phones, and then to voicemail. Received greeting but mail not recorded.
ElvorfinAuthor Commented:
I've just pinged my service provider and inbound calls to me are g711alaw primary and g711ulaw secondary, documentation says that CUE supports g711 does it actually mean g711ulaw ? Or am i clutching at straws here?
Using the multiple ... Cisco support forums.

From your comment, any externally originating call whether rang through into voicemail or answered and then forwarded to another extension, neither can be recorded.

Can not place my finger on the directive needed to allow any external originating to be saved in the cue.

Either a translation rule needs to be used to deal with the originating call being external and possible cue restriction.
ElvorfinAuthor Commented:
Yes any calls coming from an external source fails to be recorded.

I was under the impression that translation rules would only determine which mailbox the call would be directed to. The CUE seems to give me the correct message greeting for external calls. Though that could be a red herring!

I'll run some traces later when I can, and perhaps that will give us the answer.
I think cue is rejecting the external call data causes a mismatch,

You need to use a translation rule in the cme/cue peer to correct the external calling number to match cue so it is not rejected.
ElvorfinAuthor Commented:
Out of interest I have just found this :-
it would suggest that CUE will not support g711a (though it is in a CUCM environment, which uses CTI to communicate with CUE.

Or I may just be confusing myself even more!
I do not think Your issue is the codec or none of the calls would be recorded.

The cme to cue peer does the codec conversion.

Once you run the cue debug on calls internal to internal noans and then the external to extension noans
You should see why the cue rejects the save part.

Does your sip provider peer incoming on the CME have the direct-inward-dial directive?
ElvorfinAuthor Commented:
I had a look at direct inward dial some time ago but this is only valid for POTS calls on a FXO interface.
ElvorfinAuthor Commented:
OK so here's a snip of the output from tracing all voicemail traffic on the CUE

Internal call directed to CUE (working)

4867 06/05 02:59:06.648 ACCN LMED 0 Recording Started
4867 06/05 02:59:06.648 ACCN VBRW 0 Task:16000000018 WFDTMFDialogServicesAdapterImpl: RecState: terminationChars: #
4867 06/05 02:59:06.648 ACCN VBRW 0 Task:16000000018 WFDTMFDialogServicesAdapterImpl:  ENTERING RecState.start() aborted=false
4864 06/05 02:59:06.649 ACCN LMED 0 [LIB_MEDIA_RTP_SENDER] RTPReceiver::run started1
4864 06/05 02:59:06.649 ACCN LMED 0 Enter: DoubleBufferDatagramInputStream:read(Buffer), buf:Income-1@DATAI.2
14322 06/05 02:59:06.659 ACCN LMED 0 [RTPReceiverRAB-7] Reset expected seqNo to:711
14322 06/05 02:59:07.659 ACCN LMED 0 [RTPReceiverRAB-7] writeToBuffer, name=Income-1@DATAI.2, size=8160
14322 06/05 02:59:07.659 ACCN LMED 0 [RTPReceiverRAB-7] waitForEmpty: wait for consumer to clean double buffer:Income-2@DATAI.2
14322 06/05 02:59:07.659 ACCN LMED 0 [RTPReceiverRAB-7] ReadAheadThread calling writeToBuffer:Income-2@DATAI.2
14322 06/05 02:59:07.659 ACCN LMED 0 [RTPReceiverRAB-7] In writeToBuffer, name=Income-2@DATAI.2

Open in new window

And from an external call directed to CUE (not recording)

4868 06/04 12:10:51.430 ACCN LMED 0 Recording Started
4868 06/04 12:10:51.430 ACCN VBRW 0 Task:16000000014 WFDTMFDialogServicesAdapterImpl: RecState: terminationChars: #
4868 06/04 12:10:51.430 ACCN VBRW 0 Task:16000000014 WFDTMFDialogServicesAdapterImpl:  ENTERING RecState.start() aborted=false
4864 06/04 12:10:51.430 ACCN LMED 0 [LIB_MEDIA_RTP_SENDER] RTPReceiver::run started1
4864 06/04 12:10:51.431 ACCN LMED 0 Enter: DoubleBufferDatagramInputStream:read(Buffer), buf:Income-1@DATAI.2
12335 06/04 12:10:51.832 ACCN LMED 0 [RTPReceiverRAB-4] The operation timed out
12335 06/04 12:10:51.832 ACCN LMED 0 Enter: DoubleBufferDatagramInputStream:read(byte[] buf
12335 06/04 12:10:52.332 ACCN LMED 0 [RTPReceiverRAB-4] The operation timed out
12335 06/04 12:10:52.333 ACCN LMED 0 Enter: DoubleBufferDatagramInputStream:read(byte[] buf
12335 06/04 12:10:52.833 ACCN LMED 0 [RTPReceiverRAB-4] The operation timed out
12335 06/04 12:10:52.833 ACCN LMED 0 Enter: DoubleBufferDatagramInputStream:read(byte[] buf
12335 06/04 12:10:53.333 ACCN LMED 0 [RTPReceiverRAB-4] The operation timed out
12335 06/04 12:10:53.333 ACCN LMED 0 Enter: DoubleBufferDatagramInputStream:read(byte[] buf

Open in new window

So it would seem, from the RTPReceiver timeout that RTP traffic is not making it to the CUE to be recorded. Given that the CUE is on a private subnet, can I assume that this is the issue here?
I think you are missing the allow-connection sip to sip
Using as a reference.

Cme(config) voice service VoIP
allow-connections sip to sip

Is what will let the external packets to make it through to the cue recording.
Do you have as a backup an FXO coming into the CME? If you do do calls coming in on that standard POTS line, go into the cue and records without an issue?
ElvorfinAuthor Commented:
I already have the allow-connections sip to sip configured. It's that and the no supplementary-service sip moved-temporarily that connected the two SIP trunks together.

Problem now is what address is the SIP SP getting to stream the RTP to

Oh and no FXO backup
Is not the CUE IP?
You have an older system, can you see whether you can add the gambit of options for allow-connections

voice service voip

allow-connections h323 to h323
 allow-connections h323 to sip
 allow-connections sip to h323
supplementary-service h450.12
  no update-callerid

What is your
interface Integrated-Service-Engine
configuration looks like?
ip unnumbered Vlan90
 ip nat inside
 ip virtual-reassembly in
 service-module ip address
 service-module ip default-gateway

where VLAN# is the VOICE VLAN and is the CUE IP.
is your cue IP what is the default gateway for the configuration of the integrated service??
ElvorfinAuthor Commented:
Sorry for the delay in getting back to you Arnold, i've been pursuing other task.

I have all of the voice service voip options that you list there ( as well as sip to sip) except the no update-callerid

service engine is :-

interface service-engine0/1
 ip unnumbered FastEthernet0/0
 ip nat inside
 ip virtual-reassembly
 service-module ip address
 service-module ip default-gateway

The default gateway is the ip address of interface FastEthernet0/0
ElvorfinAuthor Commented:
I've opened a new question on CUE not recording as where we've got to with this thread is a bit away from the question title. Just trying to drum up any other theories that may be out there!
Any chance you can add the no update_callerid under the voice service VoIP, sip section?

You can try debugging the isdn q931
To see the setup and whether you can see when an issue for a call transfer through indicates an error/rejection.

Looking through various Cisco configs, the no update_callerId is almost always present.
I do not believe the subject of this question is correct for the situation.  The is not with 2811 blocking traffic from passing from one end through itself back
SIP <=> 2811 internally routing the connections/data to the integrated voice, .. Is not being blocked as you ccapi,ccspi and cue setup shows that the cue is receiving the setup event, but on the external originating call, something is at play.
The only remaining possibility deals with each forward/process might be trying to ..

When you have the current setup and you dial the DID to extension you are testing, what is displayed on the phone for the external call, does it only reflect the originating callerid?
If you then forward that incoming call to another extension,

The reason I am suggesting the no with only maintaining the callerid content what it is as being delivered on the sip trunk without having the CME adding each extention through which the call went to get to .......
Look at

Can you see if your router has a route defined to service-engine0/1
Which I think should be there given your internal to voicemail works.
ElvorfinAuthor Commented:
Yes the ip route statement is there.
There is an issue with the process, the setup seems to pass the call to the cue, it just times out when the call is external.
How long is the voicemail that you allow people to leave?
The internal cue the transition to the voice recording is fairly fast. While the external CUE example you posted took more than a minute which is when the timeout event is recorded.
ElvorfinAuthor Commented:
I've added no update_callerid, with no change.

Voicemail length is set at 120secs which is the default I believe.

I dont know where you are getting the timings from the debug i posted as on the external call the fist timeout is less than a second after the "Recording Started" statement.

I cant debug q931 as I don't have an ISDN connection i connect to my SP over ADSL
ElvorfinAuthor Commented:
OK so I've just done some RTP tracing (which didn't half knock out my router!) and it would appear that the RTP traffic is  following the SIP trunks in that inbound voice appears to be going:-


Given the IP addresses on the source and destination.
My Mistake, the internal had a transition of .01 seconds.

Does your 2811 have the IP or is this IP somewhere else?

Was the last cisco link helpful.  Something is missing, I can not see what.  When you access the CUE web interface and look at the mailboxes setup there, do they allow or restrict the source from which messages can be received?
Something small is missing, I can not place my finger on it.
Can you add a translation rule when a call goes into voice mail to strip out the + from the incoming calling number?

I think it is some information that is part of the calling that knocks the cue for a loop
difficulty with debugging the isdn q931 is that there might be a lot of information to sift through.
ElvorfinAuthor Commented:
I did have a look at the cisco link but didn't find anything new to be honest.

I've tried dropping the +44 from the calling number as shown below

dial-peer voice 8888 voip
 description Voicemail
 translation-profile outgoing TO_CUE
 destination-pattern 8888
 session protocol sipv2
 session target ipv4:
 dtmf-relay sip-notify
 codec g711ulaw
 no vad

voice translation-profile TO_CUE
 translate calling 4

voice translation-rule 4
 rule 1 /^.+44/ /0/

Though i get a bit confused about how translation rules work. Does that look right to you? I know the translation works as I've tested it, just not sure if i've got the dial-peer and profiles the right way round.

But it dodn't have any impact with recording a message.
there is a voice translation rule test.
that does not look right: .+ has a specific meaning
I think it should be
rule 1 /^[+]44/ //

test voice translation-rule 4 +44254552456
see what the output will be.

Does your system output the CDR?
ElvorfinAuthor Commented:

I've been away from this for a while so sorry for the lack of response. This afternoon i had another test of this but with the inbound ACL disabled on my dialer0 interface, and as if by magic audio is recorded on the CUE.

However this is a bit strange as i have the following as the first line of my ACL

permit ip host x.x.x.x0 host y.y.y.y

Which should allow all IP traffic from my SIP provider into my ADSL interface. But it would appear that it doesn't.

Does that get any bells ringing with you?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
No, it makes no sense given the call is received and is audible when answered.

That is not the line that would likely have caused the issue.

Double check the other lines one possibly dealing with the cue IP range not being allowed out might be the cause.

I.e. Explicitly Allow the cue IP range out of the dialer0 to the SIP provider network.
ElvorfinAuthor Commented:
Apologies for not posting sooner, but I've fixed the ACL issue. The solution that works is as follows.

ip access-list extended voice2
 permit tcp host <SIP IP one> host <my ip address>
 permit tcp host <SIP IP two> host <my ip address>
 permit udp host <SIP IP one> host <my ip address>
 permit udp host <SIP IP two> host <my ip address>
 deny   tcp any any eq 5060
 deny   udp any any eq 5060
 permit tcp any host <my ip address> eq ftp
 permit tcp any host <my ip address>6 established
 permit udp any eq domain host <my ip address> gt 1023
 permit tcp any host <my ip address> eq 3389
 permit tcp any host <my ip address> eq 22
 permit udp any host <my ip address> eq 21
 permit icmp any any echo-reply
 permit icmp any any unreachable
 permit icmp any any time-exceeded
 permit udp any any range 16384 32767
 deny   ip any any

Open in new window

Now not sure what to do with the question, would like to give you some points as you have helped me point in the right direction!
If suggestions I made helped you, you can award those comments points as you see fit, while selecting your own comment dealing with the ACL as the interfering entry as the solution.
ElvorfinAuthor Commented:
Pointed me in the right direction of the solution in the end.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
IP Telephony

From novice to tech pro — start learning today.