LCS Server Programmability John Lamb Consultant Microsoft UK

Agenda Overview of server APIs Review of existing features Changes in Live Communications Server 2005 Building server applications for maximum performance

Server APIs – Overview Expose SIP- No abstraction Allows application to only receive messages it requires Routing and proxy functionality Allow multiple applications to run on one server Do not impose an extensive framework on applications

Server APIs Primary components Application manifest SPL Managed extensions (optional) Performance implications in each

Component Interaction

Application Manifest What? XML formatted document Why? Describes the application to the server Application URI Filtering rules (request type, response class, strict route, etc) SPL container Where? Presented to the server when the application registers First application component to see any message

Manifest – Example <r:applicationManifest r:appUri=" tentModification" xmlns:r=" <r:requestFilter methodNames="INVITE,MESSAGE" strictRoute="true" registrarGenerated="false" domainSupported="false"/> <![CDATA[

SPL What? SPL- SIP processing language Why? Easy to use scripting language able to write powerful filter and routing rules Syntax similar to C# Very limited set of capabilities(Ex- no looping, static variables, or arithmetic) Where? Messages that pass the manifest Runs in process

SPL - SIP support Access to SIP message components providing capabilities Filtering Response codes (Ex- 302) Headers contents (Ex- Routing Proxy and respond Simple message modification Add/modify headers Change message content Access to endpoint data

SPL – Example <![CDATA[ Log("Debug", false, "Entering ContentModification.am"); userUri = GetUri(sipRequest.To); remoteHost = GetHostName(userUri); If (remoteHost != northwindtraders.com) { index = IndexOfString(sipRequest.Content, guarantee"); …

SPL – Example if (index != -1) { sipRequest.Content = Concatenate(sipRequest.Content, "\r\n**** Contoso Financial makes no binding guarantees of future performance***"); Log("Debug", false, " Message body matched substring; modified content"); } } ProxyRequest(""); ]]>

Managed APIs What? Managed API-.NET Framework SIP Class Library provides low level access to SIP semantics Why? Building standalone applications Allows application to provide more complex logic than SPL Where? Invoked from within SPL Outside of server process

Managed APIs – SIP Support All data available to SPL Messages, header contents Message content.NET facilities available for XML doc parsing, SDP, etc. Additional data Transaction objects Transaction semantics provided by the APIs Event/error handling

Managed APIs – Out Of Process Existing app integration Provides SIP awareness to legacy applications Ex- virus scanning, media relay Server security Misbehaved applications Attack vulnerability

Managed APIs – Sample <r:applicationManifest r:appUri=" gNotice" xmlns:r=" <r:requestFilter methodNames="MESSAGE,ACK" strictRoute="true" registrarGenerated="false" domainSupported="false"/> <![CDATA[ Dispatch("OnRequest"); ]]>

Managed APIs – Sample public void OnRequest(object sender, RequestReceivedEventArgs e) { string CallId = GetHeaderValue(e.Request, "Call-Id"); SessionState state = GetSessionState(e.Request); switch (state) { case SessionState.Unknown: if (e.Request.StandardMethod == Request.StandardMethodType.Ack) { UpdateSessionState(CallId, SessionState.ModifyNextIM); } else if (e.Request.StandardMethod == Request.StandardMethodType.Bye) { DeleteState(CallId); } break;

Managed APIs – Sample case SessionState.ModifyNextIM: if (e.Request.StandardMethod == Request.StandardMethodType.Message) { string ToAddr = GetHeaderValue(e.Request, "To"); if (!ParticipantWarned(CallId, ToAddr)) { e.Request.Content += "\r\n(*** This conversation may be logged. ***)"; MarkParticipant(CallId, ToAddr); } if (WarnCount(CallId) == 2) { DeleteState(CallId); } }

SPL – Performance Minimal impact SPL app should not affect engineered capacity of server Avoid registration data lookup until necessary *More significant perf impact when weighed against Managed APIs

Managed APIs – Performance Design wisely for maximum performance Filter via manifest and SPL Dispatch only when necessary By definition, SPL is better performing than Managed APIs

Performance – Best Practices Never do in SPL or managed code what you can do in a manifest Bad- <r:requestFilter methodNames="ALL"... if (sipRequest.Method == StandardMethod.MESSAGE) Good- <r:requestFilter methodNames="MESSAGE"...

Performance – Best Practices Filter before calling Dispatch() Bad- SPL: Dispatch(); Managed: if (response.statusCode != 200) return; Good- SPL: if (sipResponse.StatusCode == 200) Dispatch();

Whats New? Server roles Live Communications Server 2005 feature support Presence Optimizations Server Roles (Topology) Message origin (Access Proxy) Other SPL routing enhancements Presence based routing Flat file access Enhancements to existing objects

Whats NOT? UAC Functionality Applications do not have the capability to generate requests WMI Access from SPL Only managed applications can integrate WMI

New Features – Server Roles Several new server roles introduced Director, Access Proxy, Forwarding Proxy Each role has unique behavior DMZ Front-EndDirector Outside User Federated Company AD Access Proxy Enterprise Deployment

New Features – Server Roles Server applications may run on ANY server role What server should my app be running on? May depend on existing topology Examine message path of target activity Consider data needs Ex- Access Proxy does NOT have access to user database Deploy for performance

New Features – Presence Optimizations Recap- BENOTIFY Response- less NOTIFY Subscription piggybacking Embedding presence documents in responses SubscribeResponseNOTIFYResponseNOTIFYResponse SubscribeResponseBENOTIFY

New Features – Presence Optimization Support BENOTIFY BENOTIFY added to list of known SIP verbs Any application that inspects NOTIFY requests should inspect BENOTIFY Applications must NOT rely on responses SPL and Managed APIs Subscription piggybacking No specific features added Not ALL presence documents now available to applications in the server pools

New Features – Message Stamping Applications may require exchanging state In FE pools Stamping messages so that app runs only once per user (Ex- logging) Exchange state between application instances easily Functions provided for setting stamps and querying for existing stamps SPL and Managed APIs

New Features – Message Origin Only relevant to Access Proxy based applications Allows application logic depending upon message entering or leaving the network SPL and Managed APIs Access Proxy Federated Traffic (Outside) Enterprise Traffic (Inside)

New Features – Flat File Flat file access (SPL only) Allows SPL scripts access to delimited text files Provides a source for data- name/value pairs (128K max) Example usage- Phone routing tables Specific user set requires special handling

New Features – XML access XML document access (SPL only) GetXMLAttr(…) function Useful for Routing based on presence stored in endpoint database Inspection of SERVICE requests Attribute search based on 1st occurrence from XPath provided

Additional New Features SPL String operations Header enum- optimized header lookup Dispatch- able to pass additional parameters to managed code null may now be return from several functions Allows applications do differentiate between not found and empty string()

Backward Compatibility What about my Live Communications Server 2003 applications? Applications run in 2005 without modification No 2005 changes affect existing application Beware of 2003 app execution in FE pools Modified Applications Manifest must be updated to target 2005 if the applicaton (SPL or managed) is modified to use any 2005 features

Additional Info API Documentation on MSDN- us/lcs2005/rtc/portal.asp us/lcs2005/rtc/portal.asp us/lcs2005/rtc/portal.asp Application Deployment Guide (To be published)

© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.