Patton electronic SmartNode 4110 Series ユーザーズマニュアル

Applications

SmartWare Software Configuration Guide 

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.