Revision as of 22:13, September 12, 2012 by Valentip (talk | contribs) (→‎SIP Proxy support)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

SIP Proxy support

[Taken from HLA]

Routing

The SIP Proxy component is in charge of relaying SIP messages from the SIP endpoints to the appropriate Session Controller. Contact address of the SIP Proxy is resolved using methods described in RFC 3263.

To recover from SIP Proxy failures, SIP endpoints initiate new SIP transactions toward any SIP Proxy.

In addition, the SIP Proxy shall store SIP session information into a shared storage. Each SIP session (and subsequent sessions like consultation call) can contain several SIP dialogs established through different SIP Proxies. The session storage is required to insure that each message from the same or related SIP session is routed to the same Session Controller.

In the following picture, SIP dialogs 1 and 2 are related to the same session. [Figure, HLA: SIP Proxy routing to Session Controller]

Note: A session includes all calls that are related to each other. Most typical example of a session is a call and the associated consultation call. Each call may include one or several SIP dialogs. From a SIP perspective, all SIP dialogs from related calls belong to the same session.

Note: In SIP cluster environment, all SIP endpoints (Gateway, SBC, Phone, Feature Server and GVP) communicate with SIP Server through the SIP Proxy layer.

2.3.2 Registrar

The SIP Proxy component also acts as a SIP registrar. Bindings are maintained in a shared storage (Location Service) so that endpoints can be reached by any SIP Proxy.

In order to accept or reject a SIP registration, SIP Proxy shall implement an authentication mechanism. HTTP digest is widely accepted and can be used by SIP Proxy.

However, SIP Proxy doesn’t have knowledge of the valid AOR provisioned within the cluster. It is Feature Server which maintains the list of devices and users for the whole cluster platform. Password required for the registration authentication is therefore maintained at the Feature Server level and SIP Proxy shall communicate with Feature Server in order to verify the authentication.

Figure: SIP Proxy communicating with Feature Server (and call flow)


In this call flow, the authentication challenge is generated by SIP Proxy directly in order to avoid an additional request to Feature Server. If this is not possible, then challenge shall be requested by SIP Proxy to Feature Server before returning the 407 response.

Information provided to Feature Server shall at least include:

  • The digest challenge generated by the SIP Proxy
  • The digest response returned by the endpoint (user name can be retrieved from this response)
  • The contact address of the endpoint (this is used by the dial plan in order to locate the endpoint)

In case the user is not provisioned on Feature Server side, negative response shall be given back to SIP Proxy which will then refuse the registration.

Note: Authentication of REGISTER request ensures the SIP Proxy will deliver calls to endpoints that are proven to be what they claim to be. This is the case of incoming calls to the endpoint. However, this doesn’t prevent unauthenticated endpoints to initiate calls on behalf somebody else. In order to also authenticate outgoing calls, SIP INVITE request should also be challenged by the SIP Proxy.

2.3.3 TLib mapping

Along with SIP registration, SIP Server provides associated TLib events (EventDNBackInService and EventDNOutOfService). Those events are DN related and shall therefore be provided by T-Controller. A path shall therefore be established between SIP Proxy and T-Controller.

2.3.3.1 3rd party registration

One possibility is for the SIP Proxy to generate 3rd party REGISTER toward any Session Controller. Session Controller then notifies T-Controller in charge of the corresponding DN. And then T-Controller can distribute EventDNBackInService to registered clients.

Registration expiration timer is maintained on both SIP Proxy and T-Controller. When timer expires on T-Controller side, EventDNOutOfService is generated. When timer expires on SIP Proxy side, SIP Proxy can also send a 3rd party REGISTER indicating the end of the registration. In this case, T-Controller timer might not be needed.

2.3.3.2 ‘sipreg’ notification

Another possibility is for the SIP Proxy to send NOTIFY request to any Session Controller. RFC 3680 described the ‘sipreg’ package which is used for that purpose.

Note: Subscription is normally required before sending a SIP notification. For the specific purpose of sending ‘sipreg’ notifications to Session Controller, such subscription step could be omitted.

The rest of the chain between Session Controller and the final TLib client is identical to the 3rd party registration scenario.

Comments or questions about this documentation? Contact us for support!