Hi,

Looking for help with the anonymous call issue. In our Lync 2010 environment we noticed that all the incoming calls from anonymous number rings just 2-3 times and then it either goes to voicemail or we get missed call alert as "you received missed call from +44". Rest of the numbers works fine.

When checked the logs noticed the following:

"From: <sip:+44anonymous.invalid@xyz.com;user=phone>;epid=3D3318D010;tag=c12424ab4"

MS-Client-diagnostics:52001; reason="Client side general processing error"

We have not configured any digit manipulation on the gateway so not really sure why/how it is coming in as +44anonymous.invalid

Any help/suggestion would be really appreciated.

Thanks.

Possible it's coming in from the telco like this from someone who's trying to hide the caller id. Have you checked logs on the gateway to determine if this is what it looks like on the way in?

I agree with Anthony, the SIP Provider must be sending this as the CLI.

Hi Anthony/Paul,

Thank you for your response, checked the gateway logs and noticed that in gateway the sip id shows as:

P-Asserted-Identity : <sip:anonymous@xyz.com>

So i dont see +44 in the gateway logs, and just to add onto it we do not have any digit manipulation in place.

However we have PBX so our Lync and Avaya PBX are integrated.

Thanks

How does this flow inbound to Lync, does it go to Lync from the gateway or does it pass through Avaya first?

Hi Anthony,

From the PSTN it first passes through the Avaya PBX.

So the gateway shows it as <sip:anonymous@xyz.com>, but Lync shows it as <sip:+44anonymous.invalid@xyz.com>.  Is it possible the Avaya is adding the prefix?

Hi Anthony,

We would check the avaya part if it is adding the prefix however I have a confusion here if Avaya is adding the prefix then shouldn't we see the same sip id ( +44anonymous.invalid) in gateway logs also, as from Avaya it goes to our gateway.

I misunderstood.  I thought it was Gateway->Avaya->Lync.  

If you run this in Lync PowerShell

Get-CsTrunkConfiguration | fl identity, *translation*

Do you see any translation rules in there?

 

Yes Anothony, ran the command and we see translation rule for all the sites.

Can you post the translation rules?  If you don't see the +44 leaving the gateway, I'm wondering if you're adding it with a translation rule.

Hi Anthony,

Unfortunately I would not be able to post the translation rule but would like to mention that calls to and from local numbers should get added +44 automatically but due to some issues few numbers are not getting translated/normalized correctly. So currently our translation rule is adding +44 but not for all local numbers.

Is +44 in front of anonymous causing the problem? If lync also accepts the call as <sip:anonymous@xzy.com> then will the call come through properly.

Also why there is .invalid in <sip:+44anonymous.invalid@xyz.com>

 

I would assume then that this translation may be adding +44 to the inbound anonymous call.

What is the expected behavior of a normal call again and how is this different from what you experience with the anonymous call?  You mentioned that it rings 2-3 times then goes to voicemail or you get a missed call notification.  What would a normal call look like? 

Hi Anthony,

Just checked the call logs in the monitoring server and noticed that there are some anonynmous calls which comes in as anonymous@xyz.com and those calls work perfectly fine. Users are able to answer the call without any problem.

So some calls are coming in as anonymous@xyz.com and some as +44anonymous.invalid@xyz.com. For a normal call the unanswered one goes to voicemail only after 20 seconds but for the +44anonymous call they go straight to the voicemail without the ability to answer them.

It's odd that some are translated but not others.  What kind of gateway are you running?  Have you ever seen a +44anonymous leave the gateway while watching via WireShark? Can you reproduce by setting your cell phone to block your outbound  caller ID?

Hi Anthony,

Exactly, its strange that some anonymous call are getting translated and some are not. We are using audiocodes mediant 1000 gateway.

We have not captured wireshark for this issue,but have checked syslog and in that we didnot see +44 anonymous on the gateway log. Would try reproducing the issue like you have suggested and capture wireshark  and check again. Thanks a lot for your help and suggestion so far, would update you shortly once i reproduce the issue.

Thanks.

I'm very familiar with the Mediant, if it's not in the syslog, it's not the AudioCodes. It's got to be a Lync trunk translation rule that's over reaching. If you can find a good way to reproduce it by blocking your caller Id, it shouldn't be too hard to resolve. Also, no problem on the help, it's what I do for fun. :)

Any updates on this issue?

Hello, Atleast just to make your calls captured correctly into lync.. why not make a rule in your gateway to convert all +44anonymous@ xyz.com to anonymous@xyz.com... in this case if not much but atleast the call wont directly go into vociemail time being your rectify the issue, Thanks

Hope it will be helpful for someone who is facing the similar issue. In our case the issue got resolved by adding a manipulation in our gateway, we added +44anonymous* under source prefix and it worked.