Plugging iotum into PhoneGnome
Pages: 1, 2
iotum Call Disposition Basics
Figure 1 shows a simple block diagram of call dynamics and disposition. As a result of the iotum-PhoneGnome provisioning process, the PhoneGnome platform knows when an inbound call is addressed to an iotum user. When a call comes in, the PhoneGnome platform--functioning as XML-RPC client--makes a remote procedure call to the iotum XML-RPC server. The server examines, in real time, the connected state of the iotum user, applies the user's routing rules, and sends an XML-RPC response to the PhoneGnome platform with instructions on the call's disposition. Depending on the user's state of availability, time of the call, caller identity, and user-configured iotum call routing rules, the call is routed to the user's devices. These devices may include a desktop, mobile phone, voice mail, or more.
Figure 1. Call dynamics and disposition.
Specifically, the PhoneGnome platform forms an XML-RPC method call,
Services.CallProcessingService.process, with a single
struct argument. The argument is a dictionary of SIP headers and values.
<?xml version="1.0"?> <methodCall> <methodName>Services.CallProcessingService.process</methodN ame> <params> <param> <value> <struct> <member> <name>From</name> <value> <string>"8165551212"<sip:firstname.lastname@example.org> </string> </value> </member> <member> <name>Contact</name> <value> <string>PHONEGNOME TEST</string> </value> </member> <member> <name>To</name> <value> <string>9185551212</string> </value> </member> </struct> </value> </param> </params> </methodCall>
The response from the iotum XML-RPC server tells the PhoneGnome platform how to dispose of the call. The response is also an XML-RPC
struct, where the iotum server response action is ACCEPT, REDIRECT, or DECLINE. REDIRECT specifically includes appropriate redirect-to parameters, typically a tel: or SIP URI, and can also direct the call to voicemail.
<?xml version="1.0"?> <methodResponse> <params> <param> <value> <struct> <member> <name>action</name> <value> <string>ACCEPT</string> </value> </member> </struct> </value> </param> </params> </methodResponse>
Prior to the new XML-RPC signalling, the iotum user must be provisioned in both the PhoneGnome and iotum customer databases. This mutual provisioning is also network XML-RPC-based, and the semantic details depend on both the PhoneGnome and partner's back-office business rules. For more information on acquiring customers and provisioning them on your service, see the PhoneGnome Partner Page or please contact us at email@example.com.
PhoneGnome DeepSig in Brief
We have concentrated on a real-world use case of PhoneGnome LiteSig using lightweight XML-RPC, but let's take a quick look at PhoneGnome DeepSig. This is an overview, and will give you a sense of DeepSig's deeper addressing level. For more information on DeepSig, please contact us at firstname.lastname@example.org.
LiteSig method calls have familiar XML-RPC characteristics--method names followed by method parameters in appropriate markup. DeepSig, conversely, uses extended SIP URIs to convey protocol information:
action is the account number of the user/endpoint,
id is an opaque value identifying the transaction, and
params are action-specific parameters, if any. DeepSig actions may be initiated on inbound or outbound calls.
For example, consider this inbound SIP INVITE with a DeepSig encoded URI:
INVITE sip:*email@example.com SIP/2.0 Via: SIP/2.0/UDP 188.8.131.52:5060;branch=z9hG4bK75262cb3 From: "JOAN SMYTH" <sip:firstname.lastname@example.org>;tag=as541a0b6a To: <sip:*email@example.com> Contact: <sip:firstname.lastname@example.org> Call-ID: email@example.com CSeq: 102 INVITE User-Agent: TelEvolution Server Date: Wed, 14 Dec 2005 19:36:21 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Content-Type: application/sdp Content-Length: 263 v=0 o=root 7113 7113 IN IP4 184.108.40.206 s=session c=IN IP4 220.127.116.11 t=0 0 m=audio 15754 RTP/AVP 0 3 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - -
Such inbound calls are subject to busy and unavailable event handlers, as well as thru handling. Possible values of action are
1 for Dial/pass pattern through outbound dial handling,
2 for Busy/pass to subscriber busy event,
3 for Unavailable/pass to subscriber unavailable handler, and
4 for Thru/pass call through to next inbound dial handler.
Partner handlers, which for DeepSig are inherently SIP-based, may return the call to the PhoneGnome platform via SIP INVITE to specific URIs as:
The partner essentially owns the SIP message body, including any SDP, and can pass it back to the platform DeepSig handler as is, or modify it based on whatever other services the partner may offer.
From the PhoneGnome Mission Statement:
We remove obstacles for application service providers by providing an efficient application development and distribution platform. Our partners can deliver branded advanced services to any landline subscriber in the world, in a neutral environment, without the need to engage the local telephone company. We provide transparent and simple commercial terms, streamlined business processes, and light-weight certification requirements. Additionally, the platform helps deliver a secure, convenient, and consistent experience to users in a way that individual service providers are unable to achieve.
PhoneGnome continues to remove barriers to developers by publishing PhoneGnome FieldSig interplatform signalling protocols. The iotum case shows how easily value can be added to what were once locked-down telephony data and events. With deep or lightweight message schemes, PhoneGnome business partners can create powerful loose couplings between their respective platforms, and deliver value to their customers without building out full-featured IP voice platforms themselves.
For more information on how you can take advantage of PhoneGnome platform APIs, please contact us at firstname.lastname@example.org.
Mark Petrovic is a technologist and software developer.
Return to the O'Reilly Emerging Telephony