cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4392
Views
0
Helpful
23
Replies

UC520 SIP Trunk Hairpin issue with manual Call Transfer

rawsonfang
Level 1
Level 1

Have UC520 and use SIP trunk to ITSP for PSTN connection.Both inbound and outbound call works fine.

Have issue with hairpin issue, when the PSTN user call the inbound DID via SIP trunking,  IP phone extension could take the call and  transfer to other IP phone in other internal extensions, but if it fails if this extension need transfer the call to outside Cell phone via SIP trunking to PSTN.

Following is call flow, IP phone receives call from PSTN, press softkey " Transfer", get dial tone, and dial the outside cell phone at PSTN, cell phone ring and accepts call, press " Transfer" again on the IP phone, the call orginator and cell phone user could not hear audio at both end with silience. and it appears that UC520 still have both call active, but could not bridge the 2 calls together.

Any idea?

Thanks in advance.

23 Replies 23

I understand your point that the issue only occurs from CUE.  Because the transfer is done from CUE as a blind transfer, though, the forging of the INVITE is not a function of CUE, it is done by the IOS call control/SIP stack.  So CUE is not at fault here.  I think the issue is either a) that the original anonymous ANI is being relayed through to the outbound INVITE which the provider doesn't like or b) the way CUE transfers the call, the ANI is null and gets set to anonymous.  I don't have good enough debugs to verify this, though.

The loopback debug looks fine; I see the INVITE go out with an ANI and it looks like the call connects.

TAClogcollection.txt (which I assume is the debug with the issue) was still collected to the terminal monitor.  You can't run these debugs to the monitor and not expect it to drop messages.  As I mentioned earlier in the post, you need to collect the debugs as follows:

Router(config)# service sequence
Router(config)# service timestamps debug datetime msec
Router(config)# logging buffered 10000000 7
Router(config)# no logging con
Router(config)# no logging mon
Router(config)# voice iec syslog

Router# term len 0

Router# sh logg

Never collect debugs with 'term mon' as it is unreliable, and can cause potential high CPU as well.  Those debugs are missing the INVITE out to the provider, even, which is the critical piece to look at.  That message and many others were dropped, so it isn't possible to identify a deviation with the working scenario.  Please use the above method to collect debugs for all tests.

If you are able to get these scenarios, I can look for a deviation.  These tests should give me enough information to identify the culprit and determine if we can change behavior to get it working:

I. Enable logging buffer as mentioned above.

II. Enable the following debugs:

debug voip ccapi inout

debug ccsip all

debug voip translation

debug voip dialpeer all

III. Place a test call through CUE where the issue fails without the outgoing ANI translation for the forwarded call on.

IV. Collect that log, save it to a file labeled 'CUE transfer-failure-no translation.'

V. Place a test call through CUE where the issue fails with the ANI translation to translate all numbers to the main number.

VI. Collect that log, save it to a file labeled 'CUE transfer-failure-translation.'

VII. Place a test call through CUE with a translation on the original inbound SIP peer from the provider to translate all ANIs to a valid ANI (effectively getting rid of the original anonymous ANI from the provider).

VIII. Collect that log, save it to a file labeled 'CUE transfer-translation-on-orig-ANI.'

IV. Place a test call through a DN forwarding to a PSTN number where the issue is not seen.

X. Collect that log, save it to a file labeled 'Ephone transfer-success.'

XI. Note the calling/called/forwarded numbers for each call.

XII. Post a current configuration so we know we're looking at a current configuration.

This should shed more light on what is occurring.

For what it is worth, it may be worth trying to configure an attended transfer on CUE (ccn subsys sip/transfer-mode attended) and see if behavior changes.  This will replace the BYE-also with a REFER, and will change the way that outbound INVITE for the forwarded call is crafted.

Hi Steven,

I have reposted logs to the TAC SR yesterday, however only as requested by the engineer. Do you still want me to collect the logs as specified in your request?

All the logs are there, they just aren't broken into the filenames as you requested.

Kind Regards,

Scott Martin

By the way, we have hijacked Mr rawsonfang's thread here - which is a different issue. Can we please post any further communications in my thread as below:

sholl wrote:

Scott,

I looked at the debugs in the SR.  For the anonymous issue, I see the INVITE from the provider come in with the ANI of anonymous, so that's the provider sending *us* a restricted CLID, right?

040015: Oct 22 21:36:56.083: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:0290435450@10.10.10.4:5060 SIP/2.0
Via: SIP/2.0/UDP 203.2.134.1:5060;branch=z9hG4bKdt15rc209000rggmf681.1
From: "Anonymous";tag=1725871870-1287743872484-

203.2.134.1 is your provider right?  The debugs I'm looking at on the SR, I don't have any outbound INVITEs at all, actually.

If we were sending anonymous out to the provider, that's typically a result of privacy settings, but I don't see any debugs for outbound INVITEs to make conclusions on that, nor on the hairpin transfer.


Hi Steven,

The provider is sending us a restricted CLID - correct, as the test call was coming from O/S and CLID information is not presented in Australia for International calls typically - the same is presented if the line has blocked CLID. The "anonymous@anonymous.invalid" is not the issue - that is the inbound call leg which is working perfectly.

Please check with Victor again, as he captured all the logs necessary.

As far as I understand, the issue is with the outbound call going out as 'anonymous@sip.internode.on.net' instead of 'oursipnumber@internode.on.net' as it should (and is configured to do so).

Interestingly, the outbound peers and hairpin routing work perfectly when the CUE is taken out of the equation. I believe this issue is different to the original post - apologies for hijacking this thread.

Kind Regards,

Scott Martin

Hi Steve,

It does not appear to be Codec issue, attached please find the log and run config. Thanks for advice.

following is call flow:

One Inbound DID 718-679-9908, when call reach the UC520, it translate into extension 100, which is a shared line on Line 2 of four local IP phones.

Call Orginated from 347-886-1579  ----Call 718-679-9908  ---> Reach IP Phone

Shared line ext 100, on of the IP Phone pick up the call ---> Hit transfer ---> get dial tone --> Dial 217-390-2139 and get connection --> Hit Transfer again --> Call not complete between 347-886-1579 and 217-390-2139

ADAM CRISP
Level 4
Level 4

Hi, Can you try temporarily removing the permission term from your inbound dial-peer, and retesting?

I wondering whether when we attempt to bridge the two calls, somehow we're failling foul of the inbound security logic?

If this is the case, you could try using the b2bua keywork on the inbound trunk to try and enforce the two call bridging.

Don't forget to re-apply the permission statement afterwards.

Adam

It was IOS Bug, code upgrade resolved the issue.

What IOS were you running and what IOS did you upgrade too?

The orginal IOS code was uc500-advipservicesk9-mz.124-11.XW7,

The New System image file is "flash:uc500-advipservicesk9-mz.150-1.XA"

This has resolved both outbound PSTN Call transfer and trasnfer to voice mail issues.

most excellent.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: