The Session Initiation Protocol (SIP) is a protocol specified by the IETF. The base specification provides registration, presence and session capabilities. These capabilities are often combined to provide Voice Over IP (VoIP) functionality, but the are not limited to any particular media type.
There is a growing market for convergent applications built on ESBs. These applications need to seamlessly integrate media capabilities from communications networks. Building such applications is challenging because they must bridge disparate protocols and network types. The SIP Binding Component (SIP BC) delivers SIP capabilities directly to a JBI container enabling the development of convergent applications.
The following is documentation on the amount of abstraction the SIP BC does on behalf of the user not wanting to know everything about SIP.
SIP BC will resend any request with a ProxyAuthorizationHeader upon receiving a 407 response to that request
SIP BC will send a REGISTER Request automatically when a SU is deployed to the SIP BC
SIP BC will send a REGISTER Request (to unregister) when a SU is undeployed form the SIP BC
SIP BC will send REGISTER Requests as needed to keep the user registered with the proxy
On an incoming MESSAGE Request, the SIP BC will respond with a 200 response automatically.
The user must tell the SIP BC to send a MESSAGE Request
On an incoming INVITE Request, the SIP BC will respond with a 486 (BUSY_HERE) automatically if the user is already involved in a session
On an incoming INVITE Request, the SIP BC will respond with a 180 (RINGING) automatically if the user is not already involved in a session
On an incoming 200 (OK) Response to an INVITE Request, the SIP BC will send an ACK Request automatically.
On an incoming BYE Request, the SIP BC will respond with a 200 (OK) automatically
On an incoming CANCEL Request, the SIP BC will respond with a 200 (OK) automatically
The user must provide a final response (non-1xx) to an incoming INVITE Request
To initiate a session, the user must tell the SIP BC to send an INVITE Request
To end a session, the user may tell the SIP BC to send a BYE/CANCEL Request.
The other option to ending a session is that the user may tell the SIP BC to sendRequest of method type 'END'. The SIP BC will select whichever BYE/CANCEL/603 is appropriate.
Automated integration tests are located under sip-bc/integration. Enable the profile 'integration' to run the tests by adding -Pintegration to the command line (ex: mvn test -Pintegration).
There are two automated integration tests. The first tests sending an instant message while the second tests establishing a session.
The tests can be run against a single domain and inter-domain environment. This can be achieved by using the Spring configuration file located at sip-bc/integration/src/it/resources/sip.xml. Here you provide the host ip address for the SIP Proxy on each domain. If you do not wish to run the inter-domain tests, simply don't provide a value for proxyHost2.
There are manual tests that we run on a regular basis as regression testing. These tests are run in a single-domain, inter-domain, and single-domain with proxy authentication enabled environments.
SIP BC Consumer sends message to a Softphone
Softphone sends a message to SIP BC Consumer
SIP BC Consumer invites Softphone and establishes a session.
Softphone invites SIP BC Consumer and establishes a session.
SIP BC Consumer ends a session via sending a BYE
SIP BC Consumer receives a BYE to end a session.
SIP BC Consumer invites softphone, but immediately sends CANCEL
Softphone invites SIP BC Consumer, but immediately sends CANCEL
SIP BC establishes a session with 2 Softphones simultaneously
Softphone invites SIP BC Consumer, SIP BC Consumer sends DECLINE
Provide support for application configuration at deployment time and runtime, i.e. after an application has been packaged. Must allow for changing configuration without modifying the packaged application.
Develop a consistent logging strategy across all runtime components.
Establish a common fault/error framework for all components. This ensures consistency in fault behavior and content.
Runtime Monitoring & Management
Provide a shared model for instrumentation, aggregation, and presentation of monitoring data related to performance, activity, and status. Needs to allow for unified monitoring across CAPS 5.2. This includes the core platform as well as components.
Qualities that can be added to aninteraction with endpoints, e.g. Retry, Throttling.
MBean and WSDL extensibility elements consistency/usability
All components need to be able to recover gracefully from failure, including failure of other components internally and externally; and dealing with faults/errors in a manner that does not compromise message reliability.
Provide a transferable construct for authorization and authentication information within the context of a given invocation (parent->child)
Provide a transferable construct for transaction information within the context of a given invocation (parent->child)
Serial Processing, Message Ordering
Needs explicit support by all components; might benefit from conventions in regards to when status (DONE/ERROR) is sent back (that convention is related to TX and reliable messaging as well.)
Optimized Payload Handling
Assigning a unique stream and message identifier when sending large payloads as individual message exchanges.