Index Changes
Donated by

SIP Binding Component

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.

Further Information

Project Home

User Center

Gestalt User Center

Developer Guidelines

Gestalt Developer Guidelines

Contacts

SIP Protocol Abstraction

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.

Security

  • SIP BC will resend any request with a ProxyAuthorizationHeader upon receiving a 407 response to that request

Registration

  • 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

Messaging

  • 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

Sessions

  • 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 Tests

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.

Manual Tests

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.

'Messaging'

  • SIP BC Consumer sends message to a Softphone
  • Softphone sends a message to SIP BC Consumer

'Sessions'

  • 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

Contacts

Look Here First for Documentation

The SIP BC will be developed to include the following systemic qualities.

Click here for the expected development road map .

Application Configuration

  • 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.

Logging

Password Handling

  • Storage and Encryption of passwords.

Common Fault, Error Strategy

  • 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.

Wire Qualities

  • Qualities that can be added to aninteraction with endpoints, e.g. Retry, Throttling.

Configuration Usability

  • MBean and WSDL extensibility elements consistency/usability

Recovery

  • 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.

Security Propagation

  • Provide a transferable construct for authorization and authentication information within the context of a given invocation (parent->child)

Transaction Propagation

  • 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.

Access Count: 29
StatCounter Access Count :

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-45) was last changed on 07-Dec-07 06:46 AM, -0800 by random