Error mounting NFS Store from ESX

Just wanted to make a reminder to myself about what I encountered today:

“Just because you were told that there are no port restrictions between the 2 VLANs, don’t count on the information always being true.”

Problem

I was assisting a client move an NFS device for their vSphere environment today and kept getting the following error after re-IP-ing the device:

Error during the configuration of the host: NFS Error: Unable to Mount filesystem: The mount request was denied by the NFS server. Check that the export exists and that the client permitted to mount it

Solution

As it turns out after doing all the sanity checks on the NFS device’s management console, the problem was because there were port restrictions between the 2 VLANs.

As per the following VMware KB article:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007352

The ports required are: 111 and 2049 on UDP and TCP

NET SmartSIP X-Lite (SIP) calls to MOC Failing

This problem was interesting because it wasn’t so much the SmartSIP software but more of the networking aspect of how the NICs were setup on the Mediation server that had SmartSIP installed.

Analyzing the errors:

• Whenever I try to make a call to another signed in X-Lite phone, OCS user, the call will ring for 4 times until I get a "The person you are calling is unavailable. Please try again."

• Through reviewing the logs, I can see that SmartSIP shows it found the person but their phone never rings (X-Lite or MOC).

• The X-Lite screen reads: "Call failed: Service Unavailable"

• The SmartSIP logs shows: "NormalTemporaryFailure".

Since Google’s no help for applications such as these, I went to the install guide for help and but couldn’t find my answer there so I sat down and started thinking about the traffic between the OCS Front-End server, Mediation Server, and the SmartSIP application.

After tracing through the MOC client error logs, I found the following hint:

A SIP request made by Communicator failed in an unexpected manner (status code 80ef01f8). More information is contained in the following technical data:
RequestUri: sip:+5555@domain.com;user=phone
From: sip:unislumin@domain.com;tag=c2adc74c82
To: sip:+5555@domain.com;user=phone;tag=C9E58D6EEFCC24A2ABA5798B78861415
Call-ID: a3dc038401c844abb87eeafd9659228a
Content-type: application/sdp;call-type=audiovideo

(null)

Response Data:

183 Session Progress

101 Progress Report
ms-diagnostics: 13004;reason="Request was proxied to one or more registered endpoints";source="ocsharfe01.ad.domain.com";appName="InboundRouting"

504 Server time-out
ms-diagnostics: 1014;reason="Unable to resolve DNS A record";source="ocsharfe01.ad.domain.com";LookupFQDN="smartsip.domain.com"

Resolution:
If this error continues to occur, please contact your network administrator. The network administrator can use a tool like winerror.exe from the Windows Resource Kit or lcserror.exe from the Office Communications Server Resource Kit in order to interpret any error codes listed above.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

-------------------------------------------------------------------------------------------------------------------------------------------------------------

This is when I noticed that I wasn’t able to ping smartSip.domain.com. This was my mistake as I had asked the person who manages the root domain DNS on the BIND servers to add the record for smartSIP.ad.domain.com and not the actual smartSIP.domain.com. I’m not sure how I managed to get through the install but I’ll assume the installation process doesn’t care as much about the record as I thought it did. Once the record was added in, I am now getting the following error in MOC:

A SIP request made by Communicator failed in an unexpected manner (status code 80ef01f8). More information is contained in the following technical data:
RequestUri: sip:+5555@domain.com;user=phone
From: sip:unislumin@domain.com;tag=29f911a21d
To: sip:+5555@domain.com;user=phone;tag=C9E58D6EEFCC24A2ABA5798B78861415
Call-ID: 58dd148d93f34d7e93b19249928af2eb
Content-type: application/sdp;call-type=audiovideo

(null)

Response Data:

183 Session Progress

101 Progress Report
ms-diagnostics: 13004;reason="Request was proxied to one or more registered endpoints";source="ocsharfe01.ad.domain.com";appName="InboundRouting"

504 Server time-out
ms-diagnostics: 1007;reason="Temporarily cannot route";source="ocsharfe01.ad.domain.com";ErrorType="Connect Attempt Failure";WinsockFailureDescription="The peer actively refused the connection attempt";WinsockFailureCode="10061(WSAECONNREFUSED)";Peer="smartsip.domain.com"

Resolution:
If this error continues to occur, please contact your network administrator. The network administrator can use a tool like winerror.exe from the Windows Resource Kit or lcserror.exe from the Office Communications Server Resource Kit in order to interpret any error codes listed above.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

-------------------------------------------------------------------------------------------------------------------------------------------------------------

Definitely progress. So I went through the configuration again and thought about flow. One of the things I had to get my head wrapped around was that the configuration guide’s example was with a single NIC while our setup was using a dual NIC. I’m not exactly sure what SmartSIP recommends but Microsoft’s OCS deployment guide’s best practice is to use 2 NICs to separate data and voice traffic. After thinking more about the flow, I realized that call traffic actually gets routed to the voice NIC on port 5070 from the front-end server. A quick telnet test to the voice NIC’s IP via port 5070 shows:

Could not open connection to host, on port 5070: Connect failed.

Another ping test to the voice NIC’s IP via port 5070 shows:

Request timed out.

This got me double checking the firewall on the SmartSIP/Mediation server but it was already turned off. I went ahead and tried to have the SmartSIP/Mediation server telnet to itself, ping itself and they all worked. As all of the obvious Windows skills I used appeared to not help, this was when I had to drawn on my expired CCNA skills of routing.

Problem Solution:

Long story short, the mediation/SmartSIP server has 2 NICs. There is only 1 NIC with the gateway and this happens to be the data NIC and not the voice NIC. The voice NIC can receive the traffic from the front-end but it has no way of replying since there’s no gateway and it’s on a completely different subnet.

I went ahead and did a route add x.x.x.x mask gateway then tried again and this time I was able to call from X-Lite to MOC.

Unfortunately, X-Lite to X-Lite still doesn’t work but at least I got part of the problem sort of figured out. I still need to look into how to set the route to only be used for the voice NIC and not the data NIC.

Stay tuned for other posts about SmartSIP.

Update

After doing some research on the internet, I figured out how to specify the route for that specific interface. You basically have to do a route print then look at the Interface List section (highlighted in red).

C:\Program Files\NET- Network Equipment Technologies\SmartSIP>route print
===========================================================================
Interface List
13...a4 ba db 35 9a 8f ......Broadcom BCM5716C NetXtreme II GigE (NDIS VBD Clie
nt) #2
11...a4 ba db 35 9a 8e ......Broadcom BCM5716C NetXtreme II GigE (NDIS VBD Clie
nt)
1...........................Software Loopback Interface 1
12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
14...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
16...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.106.1.1 10.106.1.10 266
10.102.0.0 255.255.0.0 On-link 10.102.1.4 266
10.102.1.4 255.255.255.255 On-link 10.102.1.4 266
10.102.255.255 255.255.255.255 On-link 10.102.1.4 266
10.106.1.10 255.255.255.255 On-link 10.106.1.10 266
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 10.106.1.10 266
224.0.0.0 240.0.0.0 On-link 10.102.1.4 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 10.106.1.10 266
255.255.255.255 255.255.255.255 On-link 10.102.1.4 266
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 0.0.0.0 10.106.1.1 Default
===========================================================================

IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination Gateway
1 306 ::1/128 On-link
11 266 fe80::/64 On-link
13 266 fe80::/64 On-link
11 266 fe80::38d3:7e62:110f:1465/128
On-link
13 266 fe80::9523:cd2b:5daa:5204/128
On-link
1 306 ff00::/8 On-link
11 266 ff00::/8 On-link
13 266 ff00::/8 On-link
===========================================================================
Persistent Routes:
None

C:\Program Files\NET- Network Equipment Technologies\SmartSIP>

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

So now a simple:

C:\Program Files\NET- Network Equipment Technologies\SmartSIP>route add 10.106.1.0 mask 255.255.255.0 10.102.0.1 if 13
OK!

…does the trick.

NET/Evangelyze SmartSIP doesn’t like DNS name for proxy address

I’ve been setting up NET/Evangelyze’s SmartSIP application on a mediation server for a client the past 2 days and ran into a lot of issues during the install and configuring. I’ll write more about the install on another blog post but here’s a quick one:

Yes, the manual actually tells you to enter the IP address for the proxy address but my Windows best practice experience in the past was to use the name so I chose to enter the DNS A record in the proxy address instead of the IP and get a Registration error: 408 – Request Timeout.

I went ahead and changed it to the IP address, restarted X-Lite and the phone registered successfully.

Testing Exchange 2007 or 2010 hub transport server email delivery with an email with an attachment

I believe most Exchange professionals out there already know about the way of testing Exchange 2007 or 2010’s hub transport server’s delivery by simply creating an email file and dropping it into the C:\Program Files\Microsoft\Exchange Server\TransportRoles\Pickup folder for delivery but there was this one day when I was asked the following question:

Ok, so we both know how to test mail delivery with the eml file but we’re currently experiencing complaints from the client that the automatically generated emails with those reports are taking too long to get to them. Terence, do you know how we can include an attachment to test?

I didn’t know the answer and since I ended up proving that it wasn’t our Exchange that was causing the delays in delivery, I never spent the time to figure it out. After having this “to-do” list linger in my mind, I finally asked the question on our Partner Support Forums and it’s actually quite simple:

1. Open Outlook Express.
2. Create an email.
3. Add content to email.
4. Save file as eml.
5. Drop file as we usually do into the pickup folder.

The instructions made me ask myself: “Why didn’t I think about that?”

I like to give credit to where credit is due so let me thank Bob Huang from our Partner Support for this.

Now to add some value to this post, let me include the issues while trying to get this to successfully work:

Step 1 – Create the email in Outlook Express

Step 2 – Save file as someFile.eml

Step 3 – Drop the file into the C:\Program Files\Microsoft\Exchange Server\TransportRoles\Pickup folder for delivery.

Step 4 – Looks good so far

Step 5 – It appears Exchange doesn’t like this file seeing how it renamed it to “.bad”.

Let’s delete it and look at the content.

Step 6 – Content of the EML file

To: "tluk@unislumin.com"
Subject: Testing EML w/attachment delivered via Pickup Folder
Date: Wed, 25 Aug 2010 10:30:41 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000A_01CB4440.A2AA0C00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Unsent: 1
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01CB4440.A2AA0C00
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_000B_01CB4440.A2AA0C00"

------=_NextPart_001_000B_01CB4440.A2AA0C00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Testing
------=_NextPart_001_000B_01CB4440.A2AA0C00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18928">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>Testing</FONT></DIV></BODY></HTML>

------=_NextPart_001_000B_01CB4440.A2AA0C00--

------=_NextPart_000_000A_01CB4440.A2AA0C00
Content-Type: text/plain;
name="Test Attachment.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Test Attachment.txt"

Some text.
------=_NextPart_000_000A_01CB4440.A2AA0C00--

Step 5 – Analyzing content

The first problem I see is that there is no From line indicating where this mail is from so let’s modify the text to:

From: "tluk@unislumin.com"
To: "tluk@unislumin.com"
Subject: Testing EML w/attachment delivered via Pickup Folder
Date: Wed, 25 Aug 2010 10:30:41 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000A_01CB4440.A2AA0C00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Unsent: 1
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01CB4440.A2AA0C00
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_000B_01CB4440.A2AA0C00"

------=_NextPart_001_000B_01CB4440.A2AA0C00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Testing
------=_NextPart_001_000B_01CB4440.A2AA0C00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18928">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>Testing</FONT></DIV></BODY></HTML>

------=_NextPart_001_000B_01CB4440.A2AA0C00--

------=_NextPart_000_000A_01CB4440.A2AA0C00
Content-Type: text/plain;
name="Test Attachment.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Test Attachment.txt"

Some text.
------=_NextPart_000_000A_01CB4440.A2AA0C00--

Step 6 – Looks like Exchange still doesn’t like it

Step 7 – Reviewing the file again, I went ahead and removed the quotes from the “From” and the “To”.

From: tluk@unislumin.com
To: tluk@unislumin.com
Subject: Testing EML w/attachment delivered via Pickup Folder
Date: Wed, 25 Aug 2010 10:30:41 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000A_01CB4440.A2AA0C00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Unsent: 1
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01CB4440.A2AA0C00
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_000B_01CB4440.A2AA0C00"

------=_NextPart_001_000B_01CB4440.A2AA0C00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Testing
------=_NextPart_001_000B_01CB4440.A2AA0C00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18928">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>Testing</FONT></DIV></BODY></HTML>

------=_NextPart_001_000B_01CB4440.A2AA0C00--

------=_NextPart_000_000A_01CB4440.A2AA0C00
Content-Type: text/plain;
name="Test Attachment.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Test Attachment.txt"

Some text.
------=_NextPart_000_000A_01CB4440.A2AA0C00--

Step 8 – This time Exchange successfully delivers the message.

========================================================

So now some of you might ask: “Do I have to use Outlook Express because I don’t see an eml option in Outlook?”

I asked myself that question as well because the options I saw while trying to save an email in Outlook were:

Txt, OFT, MSG, HTM, HTML, MHT.

I don’t have the answer yet but I did ask Bob about this and will update this post when I get an answer.

I hope this helps someone out there that comes across this and needs to test Exchange with attachments.

Update

I got an answer back from Microsoft and it looks like Outlook cannot save messages in the EML format and this is by design. As a workaround, they suggested to use 3rd party converters such as the following:

http://bitdaddys.com/outlookEMLandMSGconverter.html

http://www.fileguru.com/apps/convert_msg_to_eml

Microsoft Office Communicator client consistently crashing when making or receiving audio calls

Problem

Ran into an interesting problem at an engineering company after deploying IM and Presence 2 months ago for them. Enterprise voice has not been deployed yet (this project just kicked off yesterday), so users have been using communicator calls to other coworkers. A small number of the 30 or so users who were in the pilot began reporting that their MOC client would crash when making or receiving audio calls. The recommendations we found through the research done on the internet and the information we got back from Microsoft was that we needed to update the MOC client with the latest patch but all of the users were already using the latest patch available from May 2010. The IT analyst here has 1 desktop and 1 laptop and while his desktop constantly crashes, his laptop doesn’t.

What’s strange is that there was a user who had no problems in the Toronto office but started experiencing issues after she moved to the Ottawa office which was on a different subnet. The voice calls from Toronto would crash but not locally in Ottawa office so a test was done from a desktop on same subnet with another laptop, the first call worked but when tried from different computer, it would crash.

After reaching out to a support engineer from the Microsoft Partner Support Forum, a recommendation to use Process Explorer from SysInternals to try and figure out what service might be causing MOC to crash. After doing a bit of poking around, we originally thought it was the iTune service but later discovered that it wasn’t.

Resolution

Long story short, the problem ended up being an application called NetSupport that was used for managing desktops. This application had a hook into the audio and video which would explain why MOC would crash upon receiving calls.

The version that caused the MOC client to crash was NetSupport for Windows 32 bit Client 10.60.6. Once we updated it to version 11.00.2, the problem went away:

I’m sure this will help me in the future when I’m troubleshooting this type of issue as I’ll always be on a lookout for any applications running in the background that may have a hook on the audio and video of a desktop/laptop.

Transferring calls from Exchange UM AA or OCS to PBX - Incoming Caller ID Matters

This problem is similar to the problem in my previous blog post: Transferring calls from Exchange UM AA or OCS to PBX - Gateway Passed # Matters found here: http://terenceluk.blogspot.com/2010/08/transferring-calls-from-exchange-um-aa.html

Problem – External user calls in via PSTN with a blocked number

Call Flow

External PSTN call comes in with the caller ID blocked. The blocked caller ID is passed to the gateway as blank.

Cisco 2801 Gateway receives the PSTN call with the caller ID blocked and pass it to the mediation server with a blank caller ID.

Mediation server passes the number to OCS as: mailto:anonymous@domain.com

OCS server passes the number to Exchange UM AA as: mailto:anonymous@domain.com

Dial by extension is selected and the extension dialed is: 291

Number is translated to: +5492 (user’s DID)

Call fails with: ms-diagnostics: 1022;reason="Cannot process routing destination";source="SomeServer-OCS01.inside.domain.com";Destination="mailto:phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone"

------------EndOfIncoming SipMessage

The following screenshot of the snooper logs show the inbound call:

Important strings found in the logs:

1. INVITE sip:+800@10.10.10.2:5060 SIP/2.0

2. FROM: "anonymous" <sip:anonymous@10.10.10.1>;tag=104C61A8-828

3. TO: <sip:+800@10.10.10.2>

4. ms-diagnostics: 1022;reason="Cannot process routing destination";source="SomeServer-OCS01.inside.domain.com";Destination="mailto:phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone"

5. ------------EndOfIncoming SipMessage

As shown in the above strings, while the TO field has an address with a +xxx number, the FROM field is now set to anonymous.

Carefully reviewing the logs show that the call flow ends up as described in the following:

1. AA is represented as +800 with the gateway translating the external number of 6095 to +800 to get pass the other problem with the TO field as number without a +.

2. Cisco 2801 Gateway receives the PSTN number as 6095 and passes it to the mediation server as +800. However, the FROM field now has an address of sip:anonymous@10.10.10.1. The logs show the following entries:

INVITE sip:+800@10.10.10.2:5060 SIP/2.0

FROM: "anonymous" <sip:anonymous@10.10.10.1>;tag=104C61A8-828

TO: <sip:+800@10.10.10.2>

**Where 10.10.10.2 is the mediation server and 10.10.10.1 is the Cisco 2801 gateway.

3. Mediation server passes the number to OCS as 6095. The log shows the following entries:

TL_INFO(TF_PROTOCOL) [2]085C.0E44::01/15/2010-20:57:03.444.00010246 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(531))

>>>>>>>>>>>>Outgoing SipMessage c=[<SipTlsConnection_12212D0>], 192.168.1.116:50184->192.168.1.115:5061

INVITE mailto:+800@domain.com;user=phone SIP/2.0

FROM: "anonymous"<sip:anonymous@domain.com;user=phone>;epid=F9C5342898;tag=70b9ddd639

TO: <sip:+800@domain.com;user=phone>

4. OCS signals Exchange UM and the mediation server passes the number to Exchange UM AA as +800 with a FROM address as sip:anonymous@10.10.10.2. The log shows the following entries:

TL_INFO(TF_PROTOCOL) [5]085C.0E38::01/15/2010-20:57:04.179.00010430 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(581))

<<<<<<<<<<<<Incoming SipMessage c=[<SipTlsConnection_12212D0>], 192.168.1.116:50184<-192.168.1.115:5061

SIP/2.0 200 OK

FROM: "anonymous"<sip:anonymous@domain.com;user=phone>;tag=70b9ddd639;epid=F9C5342898

TO: <sip:+800@domain.com;user=phone>;epid=7F0379AFD1;tag=aefea27dc

CSEQ: 134 INVITE

CALL-ID: 87ec3f0c-0e4c-4d9e-ba6e-81fa3c946e34

VIA: SIP/2.0/TLS 192.168.1.116:50184;branch=z9hG4bKffeb327d;ms-received-port=50184;ms-received-cid=34B00

RECORD-ROUTE: <sip:SomeServer-OCS01.inside.domain.com:5061;transport=tls;opaque=state:T;lr>

CONTACT: <sip:SomeServer-UM01.inside.domain.com:5066;transport=Tls>;automata

5. Dial by extension is selected and the extension dialed is 291. The log shows the following entries:

REFER-TO: <mailto:phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone>

6. The dialed extension 419 doesn’t even make it to the normalization rule that is supposed to translate it to a 4-digit DID and fails with a SIP/2.0 504 Server time-out. The log shows the following entries:

SIP/2.0 504 Server time-out

FROM: "anonymous"<sip:anonymous@domain.com;user=phone>;epid=F9C5342898;tag=97c5974872

TO: <sip:419;phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone>;tag=81D2DBAF0A35A006E2070899EC12AB7C

CSEQ: 135 INVITE

CALL-ID: baf77a8d-3a58-42b5-8abf-a13b7523b836

VIA: SIP/2.0/TLS 192.168.1.116:50185;branch=z9hG4bK1499847;ms-received-port=50185;ms-received-cid=34E00

CONTENT-LENGTH: 0

ms-diagnostics: 1022;reason="Cannot process routing destination";source="SomeServer-OCS01.inside.domain.com";Destination="sip:419;phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone"

------------EndOfIncoming SipMessage

**Note that the error here shows: Destination="mailto:phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone"

If the call is successfully routed, the @192.168.1.115;user=phone should be replaced with dialplan.domain.com@ForestFQDN.

Resolution

The resolution for this problem was to have the gateway send rewrite all calls coming in from the PSTN with a blocked caller ID to a bogus number. In our case, we rewrote it to +4165555555 thus rendering the FROM sip address as:

FROM: "anonymous" <sip:+4165555555@10.10.10.1>;tag=24FE0010-8CA

The initial connection for the call would look like this:

INVITE sip:+800@10.10.10.2:5060 SIP/2.0

FROM: "anonymous" <sip:+4165555555@10.10.10.1>;tag=24FE0010-8CA

TO: <sip:+800@10.10.10.2>

The log shows the following entries during the successful transfer:

TL_INFO(TF_PROTOCOL) [5]085C.0E38::01/19/2010-21:23:14.411.00011679 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(581))

<<<<<<<<<<<<Incoming SipMessage c=[<SipTcpConnection_3FF2357>], 10.10.10.2:5060<-10.10.10.1:58223

INVITE sip:+800@10.10.10.2:5060 SIP/2.0

FROM: "anonymous" <sip:+4165555555@10.10.10.1>;tag=24FE54A4-2029

TO: <sip:+800@10.10.10.2>

CSEQ: 101 INVITE

CALL-ID: F1944E13-47711DF-9C05FA5F-32802FEB@10.10.10.1

MAX-FORWARDS: 70

VIA: SIP/2.0/TCP 10.10.10.1:5060;branch=z9hG4bK3191DF

ALLOW-EVENTS: telephone-event

CONTACT: <sip:anonymous@10.10.10.1:5060;transport=tcp>

Reviewing the snooper trace logs, the FROM field is now rewritten with sip:+4165555555.

Here is a side-by-side snooper logs with a failed and a successful call with a blocked ID and a valid caller ID:

Note that this problem isn’t specific to AA. If a user dials an OCS user’s direct line bypassing the AA with a blocked ID, when the OCS user tries to transfer the call over to the BCM, the transfer will fail. There aren’t any issues if the OCS user transfers to another OCS user though.

I’m anxious to test this out when CS 14 RTMs.

VMware vCenter Update Manager – “Database temporarily unavailable or has network problems.”

While the following message can be caused by many reasons, I thought I’d list the one I encountered a few months back while deploying VUM.

Error Message:

There was an error connecting to VMware vCenter Update Manager - [serverName.domain.com: 8084].

Database temporarily unavailable or has network problems.

In my case, it was caused by service not running as the proper service account that has access to the database.

Once I changed the account to the proper service account that had access to the VUM database, the error message went away.