lcs server programmability john lamb consultant microsoft uk
TRANSCRIPT
LCS Server Programmability
John LambConsultantMicrosoft UK
AgendaAgenda
Overview of server APIs
Review of existing features
Changes in Live Communications Server 2005
Building server applications for maximum performance
Server APIs – OverviewServer 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 APIsServer APIs
Primary componentsApplication manifestSPLManaged extensions (optional)
Performance implications in each
Component InteractionComponent Interaction
Managed APIsManaged APIsManaged APIsManaged APIs
ApplicationApplicationManaged APIsManaged APIsManaged APIsManaged APIsManaged APIsManaged APIs
ApplicationApplication
Managed APIsManaged APIs
ApplicationApplicationApplication
SPL ScriptSPL Script
Managed APIsManaged APIsManaged APIsManaged APIs
ApplicationApplicationManaged APIsManaged APIsManaged APIsManaged APIsManaged APIsManaged APIs
ApplicationApplication
Managed APIsManaged APIs
ApplicationApplicationApplication
Application ManifestApplication Manifest
Server
Application ManifestApplication 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 – ExampleManifest – Example<r:applicationManifest
r:appUri="http://www.microsoft.com/LC/SDK/Samples/ContentModification"
xmlns:r="http://schemas.microsoft.com/lcs/2004/05">
<r:requestFilter methodNames="INVITE,MESSAGE"
strictRoute="true"
registrarGenerated="false"
domainSupported="false"/>
<r:responseFilter reasonCodes="NONE"/>
<r:splScript><![CDATA[
SPLSPL
What?SPL- SIP processing language
Why?Easy to use scripting language able to write powerful filter and routing rulesSyntax similar to C#Very limited set of capabilities(Ex- no looping, static variables, or arithmetic)
Where?Messages that pass the manifestRuns in process
SPL - SIP supportSPL - SIP support
Access to SIP message components providing capabilitiesFiltering
Response codes (Ex- 302)Headers contents (Ex- “[email protected]”)
RoutingProxy and respond
Simple message modificationAdd/modify headersChange message content
Access to endpoint data
SPL – ExampleSPL – Example<r:splScript><![CDATA[
Log("Debug", false, "Entering ContentModification.am");
userUri = GetUri(sipRequest.To);
remoteHost = GetHostName(userUri);
If (remoteHost != “northwindtraders.com”)
{
index = IndexOfString(sipRequest.Content, “guarantee");
…
SPL – Exampleif (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("");
]]></r:splScript>
Managed APIsManaged APIs
What?What?Managed API- .NET Framework Managed API- .NET Framework SIP Class Library provides low level SIP Class Library provides low level access to SIP semanticsaccess to SIP semantics
Why?Why?Building standalone applicationsBuilding standalone applicationsAllows application to provide more Allows application to provide more complex logic than SPLcomplex logic than SPL
Where?Where?Invoked from within SPLInvoked from within SPLOutside of server processOutside of server process
Managed APIs – SIP Support
All data available to SPLMessages, header contentsMessage content
.NET facilities available for XML doc parsing, SDP, etc.
Additional dataTransaction objects
Transaction semantics provided by the APIs
Event/error handling
Managed APIs – Out Of Process
Existing app integrationProvides SIP awareness to legacy applicationsEx- virus scanning, media relay
Server securityMisbehaved applicationsAttack vulnerability
Managed APIs – Sample<r:applicationManifest
r:appUri="http://www.microsoft.com/LCS/Samples/LoggingNotice"
xmlns:r="http://schemas.microsoft.com/lcs/2004/05">
<r:requestFilter methodNames="MESSAGE,ACK"
strictRoute="true"
registrarGenerated="false"
domainSupported="false"/>
<r:responseFilter reasonCodes="NONE"/>
<r:splScript><![CDATA[
Dispatch("OnRequest");
]]></r:splScript>
</r:applicationManifest>
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 – Samplecase 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 serverAvoid registration data lookup until necessary
*More significant perf impact when weighed against Managed APIs
Managed APIs – Managed APIs – PerformancePerformance
Design wisely for maximum Design wisely for maximum performanceperformance
Filter via manifest and SPLFilter via manifest and SPL
Dispatch only when necessaryDispatch only when necessary
By definition, SPL is better By definition, SPL is better performing than Managed APIsperforming than Managed APIs
Performance – Best PracticesNever 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 PracticesFilter before calling Dispatch()
Bad-SPL:
Dispatch();Managed:
if (response.statusCode != 200)return;
Good-SPL:
if (sipResponse.StatusCode == 200)Dispatch();
What’s New?What’s New?
Server rolesServer rolesLive Communications Server 2005 Live Communications Server 2005 feature supportfeature support
Presence OptimizationsPresence OptimizationsServer Roles (Topology)Server Roles (Topology)Message origin (Access Proxy)Message origin (Access Proxy)
Other SPL routing enhancementsOther SPL routing enhancementsPresence based routingPresence based routingFlat file accessFlat file access
Enhancements to existing objectsEnhancements to existing objects
What’s NOT?
UAC FunctionalityApplications do not have the capability to generate requests
WMI Access from SPLOnly managed applications can integrate WMI
New Features – Server RolesSeveral new server roles introduced
Director, Access Proxy, Forwarding Proxy
Each role has unique behavior
DMZDMZ
Front-EndDirector
Outside User
Federated CompanyFederated Company
ADAD
Access ProxyEnterprise DeploymentEnterprise 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 topologyExamine message path of target activityConsider data needs
Ex- Access Proxy does NOT have access to user database
Deploy for performance
New Features – Presence OptimizationsRecap-
BENOTIFYResponse-less NOTIFY
Subscription piggybacking
Embedding presence documents in responses
20032003
20052005
SubscribeSubscribeResponseResponseNOTIFYNOTIFY
ResponseResponseNOTIFYNOTIFY
ResponseResponse
SubscribeSubscribeResponseResponseBENOTIFYBENOTIFY
New Features – Presence New Features – Presence Optimization SupportOptimization Support
BENOTIFYBENOTIFYBENOTIFY added to list of known SIP BENOTIFY added to list of known SIP verbsverbsAny application that inspects NOTIFY Any application that inspects NOTIFY requests should inspect BENOTIFYrequests should inspect BENOTIFYApplications must NOT rely on responsesApplications must NOT rely on responsesSPL and Managed APIsSPL and Managed APIs
Subscription piggybackingSubscription piggybackingNo specific features addedNo specific features addedNot ALL presence documents now Not ALL presence documents now available to applications in the server available to applications in the server poolspools
New Features – Message Stamping
Applications may require exchanging stateIn 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 applicationsAllows application logic depending upon message entering or leaving the networkSPL and Managed APIs
Access ProxyAccess Proxy
Federated TrafficFederated Traffic(Outside)(Outside)
Enterprise TrafficEnterprise Traffic(Inside)(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 tablesSpecific user set requires special handling
New Features – XML accessXML document access (SPL only)
GetXMLAttr(…) function
Useful forRouting based on presence stored in endpoint databaseInspection 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 applicationBeware 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 InfoAdditional Info
API Documentation on MSDN- API Documentation on MSDN- http://msdn.microsoft.com/library/en-http://msdn.microsoft.com/library/en-us/lcs2005/rtc/portal.aspus/lcs2005/rtc/portal.asp
Application Deployment Guide Application Deployment Guide (To be published)(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.