Lync OPTIONS und Comfort Noise

Über die Frage ob ein Gateway zertifiziert ist oder nicht und ob ein nicht zertifiziertes Gateway vielleicht dann doch funktioniert (oder nicht) lässt sich streiten. Die Tatsache dass Lync intern alles per SSL und mit Zertifikaten absichert ist für das Gateway weniger relevant, weil der Lync Mediation Server zum Gateway durchaus auch ohne TLS per SIP spricht und die Audiodaten auch nicht zwingend verschlüsselt sein müssen. Aber ein paar Besonderheiten hat Lync, die die Zusammenarbeit mit einem Gateway erforderlich oder ratsam machen.

SIP-Options

Der Lync Mediation Server prüft regelmäßig die Funktionstüchtigkeit der angebundenen Gateways. Dies macht er durch eine "OPTIONS" Abfrage. Wer sein Gateway per SIP ohne TLS angebunden hat, kann mit Netmon diese Anfragen auch analysieren. Sie kommen alle 90 Sekunden.

Schaut man sich den Request von Lync an das Gateway an, dann sieht das erst mal ganz normal aus:

  Frame: Number = 395, Captured Frame Length = 526, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-90-8F-32-54-E1],SourceAddress:[00-26-2D-06-F8-AF]
+ Ipv4: Src = 192.168.100.100, Dest = 192.168.100.108, Next Protocol = TCP, Packet ID = 10632, Total IP Length = 512
+ Tcp: Flags=...AP..., SrcPort=55263, DstPort=5060, PayloadLen=472, 
        Seq=3561009326 - 3561009798, Ack=2368853956, Win=256 (scale factor 0x8) = 65536
- SIP: Request: OPTIONS sip:mp112.netatwork.de SIP/2.0
  - SipParser: Request: OPTIONS sip:mp112.netatwork.de SIP/2.0
   - RequestLine: OPTIONS sip:mp112.netatwork.de SIP/2.0
      Method: OPTIONS
      RequestURI: sip:mp112.netatwork.de
      SIPVersion: SIP/2.0
   - RequestHeaders: 
    + From: <sip:nawlync001.netatwork.de:5068;transport=Tcp;ms-opaque=6c2aae8345ba215d>;epid=AC0BB6AAA0;tag=83ad465816
    + To: <sip:mp112.netatwork.de>
    + CSeq: 11682 OPTIONS
      CallID: 6a90c4c9f7564975987e71cf7b3166c7
      MAX-FORWARDS: 70
    + Via: SIP/2.0/TCP 192.168.100.100:55263;branch=z9hG4bKf86921b
    + Contact: <sip:NAWLYNC001.netatwork.de:5068;transport=Tcp;maddr=192.168.100.100>
      ContentLength: 0 uSER-AGENT: RTCC/4.0.0.0 MediationServer
      HeaderEnd: CRLF

Die Antwort des Gateways fällt naturgemäß etwas umfangreicher aus. Vorausgesetzt, es unterstützt auch eine OPTIONS-Anfrage:

  Frame: Number = 397, Captured Frame Length = 1010, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-26-2D-06-F8-AF],SourceAddress:[00-90-8F-32-54-E1]
+ Ipv4: Src = 192.168.100.108, Dest = 192.168.100.100, Next Protocol = TCP, Packet ID = 3, Total IP Length = 996
+ Tcp: Flags=...AP..., SrcPort=5060, DstPort=55263, PayloadLen=956, 
       Seq=2368853956 - 2368854912, Ack=3561009798, Win=32531 (scale factor 0x1) = 65062
- SIP: Response: SIP/2.0 200 OK
  - SipParser: Response: SIP/2.0 200 OK
   + StatusLine: SIP/2.0 200 OK
   - ResponseHeaders: 
    + Via: SIP/2.0/TCP 192.168.100.100:55263;branch=z9hG4bKf86921b
    + From: <sip:nawlync001.netatwork.de:5068;transport=Tcp;ms-opaque=6c2aae8345ba215d>;epid=AC0BB6AAA0;tag=83ad465816
    + To: <sip:mp112.netatwork.de>;tag=1c808602590
      CallID: 6a90c4c9f7564975987e71cf7b3166c7
    + CSeq: 11682 OPTIONS
    + Contact: <sip:192.168.100.108:5060;transport=tcp>;expires=0
      Supported: 100rel
      Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
      Server: Audiocodes-Sip-Gateway-MP-112 FXS/v.6.20A.025
      X-Resources: telchs=2/0;mediachs=0/0
      Accept: application/sdp, application/simple-message-summary, message/sipfrag
      ContentType: application/sdp
      ContentLength: 261
      HeaderEnd: CRLF
     ResponseBody: 
- Sdp: Response: SIP/2.0 200 OK; SDP:SessionName=Phone-Call, Version=0, MediaDescription=audio 6000 RTP/AVP 8 0 101
    ProtocolVersion: 0
  + Origin: AudiocodesGW 808608061 808607926 IN IP4 192.168.100.108
    SessionName: Phone-Call
  + ConnectionInfo: IN IP4 192.168.100.108
  + ActiveTime: 0 0
  + MediaDescription: audio 6000 RTP/AVP 8 0 101
  + SessionAttribute: rtpmap:8 PCMA/8000
  + SessionAttribute: rtpmap:0 PCMU/8000
  + SessionAttribute: rtpmap:101 telephone-event/8000
  + SessionAttribute: fmtp:101 0-15
  + SessionAttribute: ptime:20
  + SessionAttribute: sendrecv

Hier ist also nicht nur die Antwort mit den erlaubten Befehlen, sondern das Gateway meldet auch die SDP-Optionen mit. In dem Response sieht man also, dass das Gateway kein Fax unterstützt.

In einem anderen Response ist das aber gut zu sehen, dass dieses Gateway viel mehr "Codecs" unterstützt, z.B. auch T38-Fax, was in der Form aber für Lync nicht erforderlich ist.

  Frame: Number = 1045, Captured Frame Length = 1244, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-26-2D-06-F8-AF],SourceAddress:[00-90-8F-23-BB-A1]
+ Ipv4: Src = 192.168.100.107, Dest = 192.168.100.100, Next Protocol = TCP, Packet ID = 3, Total IP Length = 1230
+ Tcp: Flags=...AP..., SrcPort=5060, DstPort=55585, PayloadLen=1190, 
        Seq=1002522591 - 1002523781, Ack=3592075677, Win=32528 (scale factor 0x1) = 65056
- SIP: Response: SIP/2.0 200 OK
  - SipParser: Response: SIP/2.0 200 OK
   + StatusLine: SIP/2.0 200 OK
   - ResponseHeaders: 
    + Via: SIP/2.0/TCP 192.168.100.100:55585;branch=z9hG4bK14d95eca
    + From: <sip:nawlync001.netatwork.de:5068;transport=Tcp;ms-opaque=6c2aae8345ba215d>;epid=AC0BB6AAA0;tag=b96c53bfa2
    + To: <sip:nawm1000.netatwork.de>;tag=1c1992679439
      CallID: 2a20f0b158494ff4a29f51f028a181fb
    + CSeq: 11699 OPTIONS
    + Contact: <sip:192.168.100.107:5060;user=phone;transport=tcp>;expires=0
      Supported: 100rel
      Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
      Server: Audiocodes-Sip-Gateway-Mediant 1000/v.6.20A.027.012
      X-Resources: telchs=57/3;mediachs=0/0
      Accept: application/sdp, application/simple-message-summary, message/sipfrag
      ContentType: application/sdp
      ContentLength: 472
      HeaderEnd: CRLF
     ResponseBody: 
- Sdp: Response: SIP/2.0 200 OK; SDP:SessionName=Phone-Call, Version=0, MediaDescription=image 6002 udptl t38
    ProtocolVersion: 0
  + Origin: AudiocodesGW 1992693092 1992692736 IN IP4 192.168.100.107
    SessionName: Phone-Call
  + ConnectionInfo: IN IP4 192.168.100.107
  + ActiveTime: 0 0
  + MediaDescription: audio 6000 RTP/AVP 0 18 101
  + SessionAttribute: rtpmap:0 PCMU/8000
  + SessionAttribute: rtpmap:18 G729/8000
  + SessionAttribute: fmtp:18 annexb=no
  + SessionAttribute: rtpmap:101 telephone-event/8000
  + SessionAttribute: fmtp:101 0-15
  + SessionAttribute: ptime:20
  + SessionAttribute: sendrecv
  + MediaDescription: image 6002 udptl t38
  + SessionAttribute: T38FaxVersion:0
  + SessionAttribute: T38MaxBitRate:14400
  + SessionAttribute: T38FaxMaxBuffer:1024
  + SessionAttribute: T38FaxMaxDatagram:238
  + SessionAttribute: T38FaxRateManagement:transferredTCF
  + SessionAttribute: T38FaxUdpEC:t38UDPRedundancy

In so einem Reply sind einige Werte interessant, verraten sie doch das ein oder andere über das Gateway, wenn diese mit gesendet werden.

  • Server: Audiocodes-Sip-Gateway-MP-112 FXS/v.6.20A.025
    Sofern das Gateway dieses Feld füllt, sehen Sie meist den Typ und auch die Version, was für eine Fehlersuche sehr hilfreich ist
  • X-Resources: telchs=2/0;mediachs=0/0'
    Bei einem Audiocodes kann man hier die Anzahl der "TELephoneCHannelS" sehen. Beim MP112 sind das zwei Kanäle

Und natürlich die verschiedenen SessionAttribute ein guter Indikator auf die Konfiguration des Gateways.

SIP-Trunk

Eine Anbindung per SIP Trunking / DirectSIP ist eigentlich nur eine Verlagerung des Übergangs zum Provider. Die Verbindung zwischen Mediation Server und Gateway ist nicht mehr "LAN" sondern eben eine WAN-Verbindung über das Internet oder andere IP-Anbindungen. Allerdings haben Sie hier als Administrator natürlich kaum einen Einfluss auf das Verhalten des Gateways. Umso mehr ist es wichtig, das Sie auch solche eine OPTIONS Anfrage und die Antwort betrachten können.

Gerade bei der Anbindung mit einem SIP-Trunk sind diese Informationen interessant, da manchmal die Provider aber auch Lync ihr Verhalten ändern. So war Lync bis CU1 noch nicht so pingelig, so dass Interroute als SIP-Trunk problemlos funktioniert hat. Mit CU2 auf dem Mediation Server mag Lync die Antwort auf das "OPTIONS"-Paket nicht mehr. Hier so eine Antwort von Interroute. (Stand Juni 2011)

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[],SourceAddress:[]
+ Ipv4: Src = xx.xx.xx.xx.1.xx, Dest = xx.xx.xx.xx.2, Next Protocol = TCP, 
        Packet ID = 39120, Total IP Length = 519
+ Tcp: Flags=...AP..., SrcPort=5060, DstPort=50752, PayloadLen=479, 
        Seq=1145253661 - 1145254140, Ack=2097371694, Win=54 (scale factor 0x7) = 6912
- SIP: Response: SIP/2.0 200 OK
  - SipParser: Response: SIP/2.0 200 OK
   + StatusLine: SIP/2.0 200 OK
   - ResponseHeaders: 
    + Via: SIP/2.0/TCP xx.xx.xx.xx.2:50752;branch=z9hG4bK19aa971a
    + To: <sip:xx.xx.xx.xx.1.xx>;tag=3519725415-952217
    + From: <sip:xx.xx.xx.xx.2:5060;ms-opaque=430858672875ce05;ms-opaque=430858672875ce05>;
           tag=1dd7c4d5;epid=2B87053DDB
      CallID: 924d62d32d694d4bba21f4ee32b4b383
    + CSeq: 14 OPTIONS
      Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, 
            PRACK, MESSAGE, PUBLISH
    + Contact: <sip:xx.xx.xx.xx.1.xx:5060;transport=TCP>
      ContentLength: 0
      HeaderEnd: CRLF

Auf den ersten Blick sieht alles OK aus, aber wenn Sie genau die "FROM"-Zeile ansehen, dann fehlt da das ";transport=Tcp;". Und das überprüft der Mediation Server. Man könnte nun sagen, dass Lync hier "pingelig" ist aber genau genommen sollte auf eine SIP-Anfrage auch die komplette Antwort kommen. In der Anfrage stand nämlich:

    + From: <sip:xx.xx.xx.xx2:5060;transport=Tcp;ms-opaque=430858672875ce05>;epid=2B87053DDB;tag=1dd7c4d5

Der Mediation Server in Lync 2010 CU2 toleriert so eine partielle Anfrage nicht, so dass ein SIP-Trunk erst mal unterbrochen ist. Der OptionRequest ist auch ein guter Indikator für die Verfügbarkeit und Erreichbarkeit des Gateways. Sobald diese Anfrage nicht beantwortet wird, meldet der Lync-Server dies im Eventlog:

Es ist also eine gute Idee, diese Events zu überwachen und gegebenenfalls Alarm zu schlagen.

Log Name:      Lync Server
Source:        LS Mediation Server
Date:          27.07.2011 13:18:17
Event ID:      25051
Task Category: (1030)
Level:         Error
Keywords:      Classic user:          N/A
Computer:      NAWLYNC001.netatwork.de
Description:
There was no response from a gateway to an OPTIONS request sent 
by the Mediation Server.

The Gateway peer, mp112.netatwork.de, is not responding to an OPTIONS
request sent by the Mediation Server service
Cause: The Mediation Server service cannot communicate with the Gateway
Peer Service over SIP due to network connectivity issues.
Resolution:
Please ensure network connectivity and availability of the Gateway Peer für the Mediation Server service to be able to function correctly.

Übrigens kann man so einen Alert sehr einfach unter Windows 2008 im Eventviewer direkt einstellen:

Siehe dazu auch Überwachung von Exchange - Eventlog. Damit kann zumindest ein Problem mit einem Gateway, welches sich dann in so einem Event manifestiert, gemeldet werden. Allerdings ist dies kein Ersatz für eine Logmanagement. Wer will schon viel vielen Servern unterschiedliches Events nach dem Auftreten als Alarm addieren.

Gateway ohne Options

Am Beispiel eines alten Audiocodes MP-102 kann man gut sehen, was der Mediation Server macht und wie das Gateway "nicht" reagiert. 80 Sekunden "probt" die Mediation Rolle das Gateway, welches zwar noch brav den TCP-Handshake aufbaut und die OPTIONS-Anfrage annimmt, aber diese nicht verarbeiten kann

Schaut man dann in den Syslog des Gateways, dann findet man da:

(     sip_stack)(605       ) !! [ERROR] SIPStackMngr: Message was not Parsed correctly !
(     sip_stack)(606       ) !! [ERROR] Last parsed line was :METHOD :
(     sip_stack)(607       ) !! [ERROR] The error was = unexpected 'o' 
(     sip_stack)(608       ) !! [ERROR] The Line of the error was = 2 
(     sip_stack)(609       ) !! [ERROR] The Column of the error was = 59 

Der kleine MP-102 kann einfach den Request nicht "Parsen". Die letzte Firmware 4.6 ist eben noch nicht so weit. Wieder ein Grund mehr auf "Supportete" Gateways zu setzen.

Weitere Links