locked
MSN PIC Issue RRS feed

  • Question

  • We have completed the provisioning process successfully and have received the confirmation from Microsoft that the process is complete.  Presence and IM are functioning normally for both AOL and YAHOO, but MSN presence is not working, in addition to some strange behavior with IM itself. 

     

    We are able to initiate a conversation with an MSN client from a Communicator window internally, and the message appears as expected.  The problem is that when the MSN client replies, the Communicator window displays the contact is typing a message notification, but the IM is delayed for over 1 minute, if it arrives at all.  The MSN Client indicates that the messages will be delivered when the client is back online.  Again, AOL and YAHOO presence and IM work fine.


    From what I can tell, here is the conversation as it happens per the Snooper tool:

    1. Internal INVITES external
    2. External gives an ACK
    3. Message is Delivered
    4. The External PIC client returns an INFO packet to indicate typing on the keyboard
    5. a Message is delivered exactly 1 minute later (three messages were typed in this instance)
    6. an Inbound BYE message is received from the External contact to the Internal contact.
    7. The internal client provides a BYE message

    From this, I see that there is an IN and an OUT BYE message from the same External Client....Is this expected behavior?

     

    Here is what we see with the OCS_Logger files in the final BYE mesage:

    TL_INFO(TF_PROTOCOL) [0]0DA4.075C::02/04/2008-14:44:44.235.000055f3 (SIPStack,SIPAdminLog::TraceProtocolRecord:1224.idx(122))$$begin_record

    Instance-Id: 00003AC5

    Direction: outgoing;source="external edge";destination="internal edge"

    Peer: <INTERNALPOOLFQDN>:5061

    Message-Type: request

    Start-Line: BYE sip:INTERNALSIPURI SIP/2.0

    From: <sip:EXTERNALSIPURI>;tag=207.46.27.189

    To: <sip:INTERNALSIPURI>;tag=5217cc4264;epid=cc4a8321e0

    CSeq: 6 BYE

    Call-ID: dc94d8a69f3a4fc3bd318ca17b80644e

    Via: SIP/2.0/TLS <INTERNALEDGEINTERFACE>:3063;branch=z9hG4bK521C3A6E.C846FA2C;branched=FALSE

    Max-Forwards: 68

    ms-edge-proxy-message-trust: ms-source-type=AuthorizedServer;ms-ep-fqdn=<INTERNALEDGEFQDN>;ms-source-verified-user=verified;ms-source-network=publiccloud

    Via: SIP/2.0/TLS 65.54.227.18:57861;branch=z9hG4bK31077C57.29EDFCAB;branched=FALSE;ms-internal-info="ba2yfKa_AMjNiW-2Skcs7Ln9NRMT8A";ms-received-port=57861;ms-received-cid=4C900

    Via: SIP/2.0/TLS 207.46.111.110:46677;branch=z9hG4bKYYFEQXMHGRTO;ms-received-port=46677;ms-received-cid=41ca9700

    CONTENT-LENGTH: 0

    Message-Body:

    $$end_record

     

    Monday, February 4, 2008 3:03 PM

Answers

  • It turns out that MSN is CASE SENSITIVE!  We have our RUS in Exchange that builds our addresses as

    First.Last@CompanyName.com

     

    Interestingly enough, when we sign into communicator using first.last@companyname.com, presence and IM work perfectly.

     

    MS has confirmed that a hotfix is in the works to address this.  Hopefully others read this information before pulling their hair out like I did for two weeks.

     

    Friday, February 29, 2008 3:09 PM