About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. The opinions expressed on this blog are mine and mine alone.

2009/02/10

invalid static URL in R2 MOC/Svr/Pool

 

Just ran across a strange problem.

One user could not be contacted by other users even though their presence was good.

This user could initiate conversations, and then things worked normally.

logging revealed the following:

TL_INFO(TF_PROTOCOL) [2]0AAC.0F60::02/10/2009-00:06:40.517.0000cb04 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record
Instance-Id: 00013F2B
Direction: outgoing;source="local"
Peer: 1.2.3.4:56634
Message-Type: response
Start-Line: SIP/2.0 500 The server encountered an unexpected internal error
From: "user"<sip:user@domain.org>;tag=3703bcb871;epid=de577344ca
To: <sip:user2@domain.org>;tag=A1D2F034A80C8DC2C22BC2B0BB538B47
CSeq: 1 INVITE
Call-ID: 4f0e2c32a0ac42b8a3ebfa96c1704671
Proxy-Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFF5A639D1C74445CDE716249160B5E67D5", srand="99E853C4", snum="27", opaque="753DF002", qop="auth", targetname="sip/OCS1.domain.org", realm="SIP Communications Service"
Via: SIP/2.0/TLS 1.2.3.4:56634;ms-received-port=56634;ms-received-cid=1F9900
ms-diagnostics: 1;reason="Service Unavailable";source="OCS1.domain.org";AppUri="
http://www.microsoft.com/LCS/ApiModule";reason="The application specified an invalid static forwarding url"
Content-Length: 0
Message-Body: –
$$end_record

Resolution:  removed a bogus entry in AD user object.

Telephones| IP Phones | Other

There was a text entry there rather than numeric.

Question: What is the mechanics of the UR stuffing this bogus value into somewhere that caused this failure?  I doubt I will ever know.

5 comments:

Unknown said...

I am seeing the same error, but I can IM with some users that have a bogus entry in the attribute that you state, but not all.

TFHadmin said...

This worked for me , well done that saved me a lot of time today.
I actually had a different tel number value in the primary field and my actual EV number was in the other... part of the attribute field!! once I switched them around everything sprang into life :)

TFHadmin said...

This worked for me , well done that saved me a lot of time today.
I actually had a different tel number value in the primary field and my actual EV number was in the other... part of the attribute field!! once I switched them around everything sprang into life :)

TFHadmin said...

This worked for me , well done that saved me a lot of time today.
I actually had a different tel number value in the primary field and my actual EV number was in the other... part of the attribute field!! once I switched them around everything sprang into life :)

ronin said...

Nice one been searching for days....

test 02 Feb

this is a test it’s only a test this should be a picture