locked
Remote call control problem with OCS 2007 RC1 RRS feed

  • Question

  • Hi all,

    We have a working integration of our IP PBX with OCS 2007 Public Beta using remote call control (uaCSTA messages).

    We have migrated to the new version RC1, both the server OCS and the client MOC, and we are having integration problems, apparently related to the tel URIs, according to the MOC logs.

    I have included an excerpt with the message our PBX sends to the MOC indicating that a call has been initiated (OriginatedEvent, previosly the dialog has been successfully established with the appropriate INVITE and INFOs, no errors about that). MOC sends back an OK but when it parses the message it logs some errors (
    invalid phone context) and does not show the popup indicating that the call has been originated. In this case the call is originated directly from the phone, so when the PBX sends the message to MOC through OCS, the client should show a popup indicating a call has been originated.
    The same happens with other events such as DeliveredEvent or EstablishedEvent.

    As you can see in the logs, we send the line URI and device identifiers with the format tel:<number>, the same format used for the users' Line URI.
    As I said at the beginning this is working fine with Public Beta, but it fails with RC1. Is it possible that MOC now expects a different format in the TEL URI?


    Code Snippet

    06/12/2007|16:25:18.027 B24:3A0 INFO :: Data Received - 172.24.75.101:5060 (To Local Address: 172.24.75.103:1465) 1559 bytes:
    06/12/2007|16:25:18.037 B24:3A0 INFO :: INFO sip:172.24.75.103:1465;transport=tcp;ms-opaque=a434de236d;ms-received-cid=00000F00;grid SIP/2.0

    Via: SIP/2.0/TCP 172.24.75.101;branch=z9hG4bK82CC158C.C131CA20;branched=FALSE;ms-internal-info="ba68R2vIfyHkUoYQTHAwaWKC9zbk_BMcogxAu7-wAA"

    Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFF87AEDDBC72DEE564D20578B4B83A13D9", srand="40803467", snum="26", opaque="ED86C895", qop="auth", targetname="sip/OCS.danielu.net", realm="SIP Communications Service"

    Max-Forwards: 69

    Via: SIP/2.0/TCP 172.24.75.191:5060;branch=z9hG4bK5a9532fe75b0062984ba353eb46666ca;ms-received-port=50509;ms-received-cid=1000

    CSeq: 2 INFO

    From: <sip:irvoz@armando.teldat.es>;tag=949468

    To: "Susana Juan" <sip:susanaj@danielu.net>;tag=b72bd11c62;epid=216266b284

    Call-ID: 15db87e14ec4437491caac1b08d43f25

    User-Agent: IRVOZ uaCSTA Gateway

    Content-Disposition: signal; handling=required

    Content-Type: application/csta+xml

    Content-Length: 602



    <?xml version="1.0" encoding="UTF-8"?>
    <OriginatedEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3"><monitorCrossRefID>tel:1002</monitorCrossRefID>

    <originatedConnection><callID>1181678226.40</callID><deviceID>tel:1002</deviceID></originatedConnection>

    <originatingDevice><deviceIdentifier>tel:1002</deviceIdentifier></originatingDevice><callingDevice>

    <deviceIdentifier>tel:1002</deviceIdentifier></callingDevice><calledDevice><deviceIdentifier>tel:1001</deviceIdentifier>

    </calledDevice><localConnectionInfo>connected</localConnectionInfo><cause>normal</cause></OriginatedEvent>
    06/12/2007|16:25:18.037 B24:3A0 INFO :: End of Data Received - 172.24.75.101:5060 (To Local Address: 172.24.75.103:1465) 1559 bytes
    06/12/2007|16:25:18.037 B24:3A0 TRACE :: SIP_STACK::FindProviderSAContext SA_CONTEXT found:sip/OCS.danielu.net- 000FC808, SA list entry 01B127A8, this 01A78060
    06/12/2007|16:25:18.037 B24:3A0 TRACE :: SIP_MSG_PROCESSOR::GetSAListEntry SA [000FC808] targetname sip/OCS.danielu.net, auth 8, this 0132B27C
    06/12/2007|16:25:18.037 B24:3A0 TRACE :: SIP_MSG_PROCESSOR::AddSAToList found SA [000FC808] from list entry [01BE7D00] with TargetName: sip/OCS.danielu.net Auth: 8 , this 0132B27C
    06/12/2007|16:25:18.037 B24:3A0 TRACE :: SIP_MSG_PROCESSOR::GetSAListEntry SA [000FC808] targetname sip/OCS.danielu.net, auth 8, this 0132B27C
    06/12/2007|16:25:18.037 B24:3A0 TRACE :: verified buffer: <Kerberos><40803467><26><SIP Communications Service><sip/OCS.danielu.net><15db87e14ec4437491caac1b08d43f25><2><INFO><sip:irvoz@armando.teldat.es><949468>

    <sip:susanaj@danielu.net><b72bd11c62><><><>-length-196. signature:602306092A864886F71201020201011100FFFFFFFF87AEDDBC72DEE564D20578B4B83A13D9
    06/12/2007|16:25:18.037 B24:3A0 ERROR :: SIP_STACK::MapDestAddressToNatInternalAddress m_pDirectPlayNATHelp is NULL. Setting *pIsDestExternalToNat to FALSE
    06/12/2007|16:25:18.037 B24:3A0 TRACE :: signed buffer: <Kerberos><77552561><21><SIP Communications Service><sip/OCS.danielu.net><15db87e14ec4437491caac1b08d43f25><2><INFO><sip:irvoz@armando.teldat.es><949468>

    <sip:susanaj@danielu.net><b72bd11c62><><><><200> - length- 201. SSPI context:992976-1081352.
    06/12/2007|16:25:18.037 B24:3A0 INFO :: Sending Packet - 172.24.75.101:5060 (From Local Address: 172.24.75.103:1465) 878 bytes:
    06/12/2007|16:25:18.037 B24:3A0 INFO :: SIP/2.0 200 OK

    Via: SIP/2.0/TCP 172.24.75.101;branch=z9hG4bK82CC158C.C131CA20;branched=FALSE;ms-internal-info=

    "ba68R2vIfyHkUoYQTHAwaWKC9zbk_BMcogxAu7-wAA"

    Via: SIP/2.0/TCP 172.24.75.191:5060;branch=z9hG4bK5a9532fe75b0062984ba353eb46666ca;ms-received-port=50509;ms-received-cid=1000

    From: <sip:irvoz@armando.teldat.es>;tag=949468

    To: <sip:susanaj@danielu.net>;tag=b72bd11c62;epid=216266b284

    Call-ID: 15db87e14ec4437491caac1b08d43f25

    CSeq: 2 INFO

    Contact: <sip:susanaj@danielu.net;opaque=user:epid:BZwFw3EqOFmRF-kFNFKJ9AAA;gruu>

    User-Agent: UCCP/2.0.6249.0 OC/2.0.6249.0 (Microsoft Office Communicator)

    Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="ED86C895", crand="77552561", cnum="21", targetname="sip/OCS.danielu.net", response="602306092a864886f71201020201011100ffffffff4d56ee5bcae3bff8240fbe710a78ad7c"

    Content-Length: 0




    06/12/2007|16:25:18.037 B24:3A0 INFO :: End of Sending Packet - 172.24.75.101:5060 (From Local Address: 172.24.75.103:1465) 878 bytes
    06/12/2007|16:25:18.037 B24:3A0 INFO :: CUccRemoteCallControlEndpoint::NotifyIncomingInfo - Handling event OriginatedEvent with CSeq 2
    06/12/2007|16:25:18.037 B24:3A0 INFO :: CUccRemoteCallControlEndpoint::IsLocalECMADeviceID - Type=1,Matched tel:1002 with local device-ID tel:1002
    06/12/2007|16:25:18.037 B24:3A0 WARN :: CUccRemoteCallControlEndpoint::FindSessionByCallID - Failed to find session for call-id=1181678226.40
    06/12/2007|16:25:18.037 B24:3A0 INFO :: CUccRemoteCallControlEndpoint::HandleOriginatedEvent - Creating new session with call-id 1181678226.40
    06/12/2007|16:25:18.037 B24:3A0 INFO :: CUccSessionParticipantEndpoint::SetInternalId - Can't set internal ID to tel:1002
    06/12/2007|16:25:18.037 B24:3A0 INFO :: CUccRemoteCallControlSession::FindParticipantByECMADeviceId - Type=1,Participant with device-ID tel:1001 not found
    06/12/2007|16:25:18.037 B24:3A0 INFO :: CUccRemoteCallControlSession::IsLocalECMADeviceID - Type=1,Failed to match device-ID tel:1001
    06/12/2007|16:25:18.037 B24:3A0 TRACE :: CUccSession::InternalAddParticipant - Adding participant tel:1001
    06/12/2007|16:25:18.037 B24:3A0 INFO :: CUccRemoteCallControlEndpoint::CheckAndAddNewParticipant - Session=000F54C0,uri=tel:1001,dynamic-id=(null),StaticFound=0,DynamicFound=0
    06/12/2007|16:25:18.037 B24:3A0 INFO :: CUccSessionParticipant::InternalSetState [01C4C200] - state: 0x1->0x2
    06/12/2007|16:25:18.037 B24:3A0 ERROR :: CUccRemoteCallControlSession::GetCallControlTransaction - matching phone control transaction NOT found
    06/12/2007|16:25:18.037 B24:3A0 INFO :: CUccRemoteCallControlSession::NotifyCallControlTransaction - failed in GetCallControlTransaction 0x80004005
    06/12/2007|16:25:18.047 B24:3A0 INFO :: Function: TEL_URL::ParseTelUri
    06/12/2007|16:25:18.047 B24:3A0 ERROR :: HRESULT failed: 80ee0012 = ((HRESULT)0x80EE0012L). invalid phone context
    06/12/2007|16:25:18.047 B24:3A0 INFO :: Function: TEL_URL::Initialize
    06/12/2007|16:25:18.047 B24:3A0 ERROR :: HRESULT API failed: 80ee0012 = ParseTelUri(sszTelUri, ulTelUriLen)
    06/12/2007|16:25:18.047 B24:3A0 INFO :: Function: CUccUriManager::ConvertUri
    06/12/2007|16:25:18.047 B24:3A0 ERROR :: HRESULT failed: 80ee0012 = hr. Failed to init tel url
    06/12/2007|16:25:18.047 B24:3A0 INFO :: Function: TEL_URL::ParseTelUri
    06/12/2007|16:25:18.047 B24:3A0 ERROR :: HRESULT failed: 80ee0012 = ((HRESULT)0x80EE0012L). invalid phone context
    06/12/2007|16:25:18.047 B24:3A0 INFO :: Function: TEL_URL::Initialize
    06/12/2007|16:25:18.047 B24:3A0 ERROR :: HRESULT API failed: 80ee0012 = ParseTelUri(sszTelUri, ulTelUriLen)
    06/12/2007|16:25:18.047 B24:3A0 INFO :: Function: CUccUriManager::ConvertUri
    06/12/2007|16:25:18.047 B24:3A0 ERROR :: HRESULT failed: 80ee0012 = hr. Failed to init tel url


    Thanks in advance.

    Armando Mata
    Tuesday, June 12, 2007 3:35 PM

Answers

  • Hi

     

    Try adding phone-context=dialstring to the line URI

    for example tel:1002;phone-context=dialstring

     

    Tuesday, June 12, 2007 7:23 PM

All replies

  • Hi

     

    Try adding phone-context=dialstring to the line URI

    for example tel:1002;phone-context=dialstring

     

    Tuesday, June 12, 2007 7:23 PM
  • That worked, thanks. The only problem now is that we have a little work to do in our gateway in order to support this, because the phone-context must be used not only in the line URI, but also in all the device identifiers.

    Besides, I had to change the phone number normalization rules for the Address Book Server, to include also the phone-context parameter when the phone numbers are generated, otherwise MOC would not recognize any phone numbers for the users.

    What is strange is that the Public Beta did not complain about tel URIs with format tel:<number>, and they are not supported in RC1...

    Regards,
    Armando Mata
    Wednesday, June 13, 2007 9:16 AM
  • Hi,

     

    I have the similar problem in RTM (MSDN Version).

    I tried to change the URI, but the GUI complains about the format, when I enter "tel:4122;phone-context=dialstring"

     

    Best Regards

    Alex

     

    Tuesday, August 21, 2007 12:53 PM
  • Hi All,

     

    I have a similar problem with phone-contest.

     

    first the GUI complains about the phone-context string in TEL URI

     

    second when I dial to a forwarded OCS2007 contact the calls fails because of a phone-context=unknown!!

     

    Any idea on how to work around this phone-context= unknown?

     

    Thank you beppe

     

    Thursday, October 4, 2007 10:52 AM
  • Hi All

     

    We have the same problem with phone-context=dialstring.

    I found some errors in the Communicator log file (%systemdrive%\%userprofile%\Tracing\Communicator-uccp-0.uccplog) saying:

    CUccRemoteCallControlSession::IsLocalECMADeviceID - Type=0,Failed to match device-ID telStick out tongueHONENUMBER;phone-context=dialstring

     

    After some tests I found a way by using the AD's OtherPhone Attribute. If you add telStick out tongueHONENUMBER;phone-context=dialstring to the users/contacts OtherPhone AD attribute the system can make a reverse number lookup!

     

    Hope it helps

     


     

    Friday, August 15, 2008 1:42 PM