Filter
Top Products
Applications 570
SmartWare Software Configuration Guide 46 • Context SIP gateway overview
Inbound Registration
With the according license, the back-to-back user agent can allow registrations from other user agents. There-
fore, identities must be configured with a registration inbound face. Contacts to forward requests for this iden-
tity can be configured or added dynamically with REGISTER requests.
If the gateway has to accept register requests for unknown identities or for any identity that belongs to a certain
domain, there can be a “default” identity-group configured. The configuration of the identity-group “default”
with the registration inbound face allows registration for any identity in this location-service that is not explic-
itly configured.
location-service INALP
domain inalp.com
identity-group default
registration inbound
identity 400
registration inbound
lifetime default 4000 min 600 max 36000
contact 172.16.40.22 switch IF_SIP priority 500
context sip-gateway GW_SIP
sip-interface SIP_WAN
bind interface IF_WAN port 5060
context sip-gateway GW_SIP
bind location-service INALP
If the gateway receives an incoming REGISTER request, the following procedure takes place:
1. Determine to which sip interface in the context cs the request should be forwarded. This happens accord-
ing the same rules as an incoming INVITE is forwarded. Outgoing calls to the registered contacts will
pass through the same sip interface as the incoming REGISTER request.
2. Check request-uri. The host part of the request-uri must match a domain of a location-service which has
configured imperative “authoritative” and is bound to the context sip-gateway which received the request.
3. Check to header. The host part of the to-uri must match the host part of the request-uri.
4. Check if registration is allowed. There must be an identity in the location-service that match with name or
alias the host part of the to-uri or a identity-group “default” with a registration inbound face configured.
5. Create a dynamic identity if the identity to register does not already exist. This happens when the identity-
group “default” is configured with a registration inbound face. The dynamic created identity inherits from
the identity-group “default”.
6. Add all contacts with expires≠0 to the requested identity. The expiration time is taken out of the expire
parameter from the contact or from the expire header. This time is adjusted to fit into the configured life-
time boarder. If there is no expires parameter the default expired from the configured lifetime is taken.
7. Remove all contacts with expires=0 from the requested identity.
8. Remove a dynamic identity if the identity contains no more contacts.