locked
Park-O-Meter Question - Proper Display on SNOM 821 RRS feed

  • Question

  • A question on proper display names in ParkOMeter, which may help me understand an issue we are having with our SNOM 821 phones. Let me explain. When we receive a call from the outside, the callerID on the desk phone is correct. However, when we pick up the call, this changes to the SIP connection string. If I transfer the call to another extension, the display is correct. It seems to JUST be related to outside calls when they are first received.

    At first, this seemed completely like a SNOM issue until I saw this when monitoring parked calls. Shouldn't outside calls be shown with something other than the FE server name? (Actual domain is blacked out)

    I would think that the "Parkee" should be the caller ID information, so my overall issue may be related to Lync, not my SNOM phone. (When receiving with the Lync client, I see the connection string, but the callerID appears about a second later.)

    This is the connection string we are seeing on the phone: sip:lync-frontend.domain.com@domain.com;gruu;opaque=srvr:MediationServer:P97w7AiLzFuwdk2ccCBNvwAA;grid=71c03acd21cf4fa7a2230c2aac479445

    Thank you in advance for your assistance!

    Bradford Schleifer


    Tuesday, June 19, 2012 3:21 PM

All replies

  • Hi,

    I recommend trying to enable the logging tool with enable mediation component on Mediation Server then get the details report to check why the display information changed. Regarding how to enable logging on lync find the below url which will help.

    Logging tool:

    http://technet.microsoft.com/en-us/library/gg558599.aspx

    http://www.ultimate-communications.com/2010/11/how-to-troubleshoot-lync-using-lync-server-logging-tool-snooper-v4/


    Regards,

    Kent Huang

    TechNet Community Support ************************************************************************************************************************

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question.


    • Edited by Kent-Huang Thursday, June 21, 2012 9:06 AM
    Thursday, June 21, 2012 9:06 AM
  • Greetings Kent,

    I have run log checks, and have not yet updated this thread. It appears the issue may be related to Lync and how it behaves with response groups. I'll do some testing today with DIDs. However, notice the SIP header. The contact field is populated with server information, not call data.

    That is the same information that is showing on the display for the phone!

    -0-

    TL_INFO(TF_PROTOCOL) [1]0B34.2328::06/21/2012-01:22:18.410.000ba098 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(125))$$begin_record
    Trace-Correlation-Id: 3992217439
    Instance-Id: 00115606
    Direction: incoming
    Peer: lync-frontend.domain.local:60185
    Message-Type: request
    Start-Line: INVITE sip:+13305551212@domain.com;user=phone SIP/2.0
    From: "+13304445555"<sip:+13304141111@domain.com;user=phone>;epid=3838403FEE;tag=f2b04cb8
    To: <sip:+13305551212@domain.com;user=phone>
    CSeq: 3163 INVITE
    Call-ID: e2486f01-1128-408d-93d5-494c405855d3
    MAX-FORWARDS: 70
    VIA: SIP/2.0/TLS 192.168.1.2:60185;branch=z9hG4bKc2a9aac
    CONTACT: <sip:lync-frontend.domain.local@domain.org;gruu;opaque=srvr:MediationServer:P97w7AiLzFuwdk2ccCBNvwAA;grid=46d4ae82cab245bd966afec7eb1e33d3>;isGateway
    CONTENT-LENGTH: 3880
    SUPPORTED: replaces
    SUPPORTED: ms-safe-transfer
    SUPPORTED: ms-bypass
    SUPPORTED: ms-dialog-route-set-update
    SUPPORTED: timer
    SUPPORTED: 100rel
    SUPPORTED: gruu-10
    USER-AGENT: RTCC/4.0.0.0 MediationServer
    CONTENT-TYPE: multipart/alternative; boundary=BmnLH3xgLZirO0ZDG9cSVzECqQQzJG0X
    ALLOW: ACK
    ms-endpoint-location-data: NetworkScope;ms-media-location-type=intranet
    ms-call-source: non-ms-rtc
    ms-trunking-peer: 4.53.160.139;User-Agent="CCNQ internal-ocs"
    Session-Expires: 1800
    Min-SE: 90
    Allow: CANCEL,BYE,INVITE,REFER,NOTIFY,PRACK,UPDATE




    Thursday, June 21, 2012 11:35 AM
  • Any assistance with this issue would be appreciated. This seems more like a problem with Lync than the Snom phones based on the data above.
    Wednesday, June 27, 2012 8:21 PM
  • The contact field should not be used for display, the display should be based on the From field and/or P-Asserted-Identity [http://www.ietf.org/rfc/rfc3261.txt].

    <snip from http://www.ietf.org/rfc/rfc3261.txt>

    8.1.1.8 Contact The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in this specification, that includes only the INVITE request. For these requests, the scope of the Contact is global. That is, the Contact header field value contains the URI at which the UA would like to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs.

    </snip>

    Look at section 8.1.1.3 for information about the "From" header. The P-Asserterd-Identity header is described in rfc3325.

    I will do some tests in my lab and see how the call park-o-meter behaves and perhaps even check on a SNOM phone if i can get one.

    Thursday, July 5, 2012 7:06 AM
  • Much appreciated. I have an open ticket with SNOM as well so I will pass on this information and update the thread when I know more.
    Thursday, July 5, 2012 2:12 PM