SIP Gateway

A SIP (Session Initiation Protocol) gateway can be used to connect a Sametime deployment to another service, whether that be another external Sametime deployment, or a completely different service (AIM, Yahoo, Jabber).

Warning

This topic is incomplete, so I've just left my notes in place below. Please understand that this is all drawn from observation and speculation, not from actual knowledge of the inner workings of the SIP gateway(s)

Notes

  • a conversation with an external user has five necessary points: the local user; the local user's Sametime server; that Sametime server's SIP gateway; the remote users's SIP gateway; the remote user. There may be additional points between the remote SIP gateway and the remote user.
  • the external user does not necessarily need to be using Sametime
  • SIP -> Sametime user conversations seem to require RC2/128 encryption.
  • Sametime -> SIP conversations can be specified with None or RC2/128 encryption.
  • There are no guarantees on encryption from the local SIP gateway outwards.
  • future federation with AIM, Yahoo, Google Talk may result in identifiers of the form "@E aimuser@aol.com", "@E yahoouser@yahoo.com", "@E gmailuser@gmail.com", etc.
  • Why doesn't the SIP gateway use the community field in the user ID block instead of an "@E " prefix and a federation-mapped suffix?

User ID Routing

The SIP gateway will be used for awareness and messaging with users marked as external. External users are indicated by the simple expedient of prepending the three character string "@E " to their identifier. In effect, when talking to an external user, you're talking to the SIP gateway, which is then translating the conversation to SIP and routing it over a federated connection to another server. User routing is done based on suffix matching of the user identifier. For example, identifiers ending in "compand1.com" will all be routed via the same federated connection. If a federated connection cannot guarantee uniform suffixes on identifiers it handles, the gateway can be configured to effectively create a virtual suffix. For example if company2 used simply a user's name as the identifier, the suffix ".company2.ext" could be appended to help mark those users for routing. Such a virtual suffix would need only be unique to that particular SIP gateway.

Feature Abstraction

Since messaging an external user requires that the conversation be converted from the Sametime protocol to SIP (specifically SIMPLE maybe?), only the barebones features of status awareness and plaintext messages seem to be supported. todo: try conferencing? Specialty features such as the NotesBuddy IM Extensions cannot be safely translated, thus are not permitted.

Toolbox
Favorite Categories