Vendors and Connections


Vendors


Vendors are logical entries in the system representing carries to which calls will be sent for termination. Each Connection belongs to only one Vendor, while a Vendor can have many Connections that belong to it.

The following figure illustrates this concept:



Here you can see a system which has 6 connections that correspond to 3 different vendors.  Each connection represents a separate SIP-PSTN gateway located in a different place.    


Connections


Connections are logical entries in the system representing call destinations.  For example, a Connection can represent a specific SIP-PSTN gateway in your network, another SIP softswitch that belongs to your termination provider, some SIP IVR, a conference server, etc.


Connection Parameters


Each Connection has several parameters associated with it:


  • Destination – IP address or DNS name of the remote SIP device/software where outgoing calls will be sent
  • Username – username associated with the SIP digest authentication (if required by the Connection destination)
  • Password – password associated with the SIP digest authentication (if required by the Connection destination)
  • CLD Translation Rule – translation rule applied to the CLD before sending the outgoing call to the Connection destination
  • CLI Translation Rule – translation rule to be applied to the CLI before sending the outgoing call to the Connection destination
  • Capacity – maximum number of simultaneous calls accepted by the Connection destination. Value of "-1" means that there is no limit
  • Enforce Capacity – if enabled instructs the Softswitch to limit (by the value of the Capacity parameter) the number of simultaneous calls established to a particular Connection
  • Use Media Relay – policy for using media relay (RTPProxy) when calls are sent to the Connection,  see more details here https://support.sippysoft.com/solution/articles/3000051482-media-relay-usage-cases
  • Preferred Media Relay - option to select between built-in RTP proxy and external media gateway (if you have one) 
  • Single Outbound Port - when enabled, SIP requests would be sent from the 5060 port, otherwise they would be sent from one of the B2BUA ports configured in the system ( for example, 5061,5065,5066,5067,5068,5069,5070,5071)
  • Huntstop SIP Codes – comma-separated list (without spaces) of SIP "final negative response" codes (e.g: 486,503,501). If any of the codes is received from the Connection, the Softswitch stops hunting (i.e. it prevents the switch from trying to connect the call to an alternative Connection).  For example, if a particular Connection is known to correctly report when the PSTN destination number is busy by sending 486 "Busy Here".  The parameter can be set to 486.  Huntstop is applied to any SIP codes like 500, or 486.  The Huntsop parameter also works for 1xx SIP codes, like 180, and 183 - this is a recent change available starting from Sippy 5.0 (© 2019)
  • Outbound proxy - is a feature that allows you to set a specific outgoing IP and port for the INVITE message (e.g. vendor connection IP), so that the INVITE packet will be sent to the defined <IP:port> named in the 'Outbound proxy' field.  The request URI field will contain the <IP:port> from the 'Destination' field

  •  Allowed RURI Params - The field "connections.pass_ruri_params" contains a comma separated list of parameter names that pass information to the Vendor such as "User" or remove information such as "Test" from the invite. For example :

INVITE sip:120650024495@223.49.26.5;user=phone;test=value SIP/2.0


In the example above, the connections.pass_ruri_params contains 'user'.  If both parameters should be passed then the connections.pass_ruri_params needs to contain 'user,test'


  • Max CPS- maximum allowed number of outbound call attempts per second for a connection
  • Blocked - if checked, the connection will not be used in routing
  • Random Call-Id - select this option to generate a call ID to replace the one from the inbound invite
  • Ignore LRN - do not perform LRN dipping
  • Reply Timeout, sec - the time that Sippy will wait for the "100" reply before trying the next connection
  • Outbound IP - source IP that will be used in outbound messages to the Vendor
  •  Enable Diversion - enables the header mentioned, see https://support.sippysoft.com/solution/articles/3000061100-diversion-header-support-per-rfc5806
  •  From Domain - modifies the Invite to a Vendor by changing the IP in the "From" field to a domain name
  •  Accept 3xx Redirects - selecting this option allows the switch to accept and process 3xx responses.  Read more in this article: https://support.sippysoft.com/solution/articles/3000072772-support-for-3xx-sip-redirect-response-codes
  •  Redirect Depth Limit - setting which controls the maximum number of subsequent redirects when a redirected call receives a 3xx response.  In case of a "300 Multiple Choices" redirect, the "Redirect Depth Limit" restricts the maximum number of hunt attempts
  •  Privacy Mode - this setting replaces the CLI with a number received from the caller in either P-Asserted-Identity or Remote-Party-ID header format.  See sample uses below:
    • Off - neither the P-Asserted-Identity number, nor the Remote-Party-ID header would affect the CLI that is sent to the Vendor
    • P-Asserted-Identity - the CLI would be replaced with the number from the P-Asserted-Identity header.  If a CLI translation rule is configured for the Connection, it will be applied to the P-Asserted-Identity number before the INVITE is sent to the vendor
    • Remote-Party-ID - the CLI would be replaced with the number from the Remote-Party-ID header.  If a CLI translation rule is configured for the Connection, it will be applied to the Remote-Party-ID number before the INVITE is sent to the Vendor
  • Use CLI as P-Asserted-Id  - support For SIP Asserted Identity within Trusted Networks, see https://support.sippysoft.com/en/support/solutions/articles/84156-support-for-sip-asserted-identity-within-trusted-networks-rfc-3325-
  • Asserted-Id Tr. Rule - translation rule which permits the changing of the outgoing Asserted Identity.  The translation rule is always applied to the Asserted Identity whether it was received through the incoming call or it was generated locally.  If the translation results in an empty string then the P-Asserted-Identity header is not sent at all
  • Diversion Header - the switch operator can set the Diversion Header Tr. Rule in order to change the Diversion number according to the requirements of the Vendor.  This feature doesn't support the replacement of parameter in Diversion header. Read more in this article: https://support.sippysoft.com/solution/articles/3000061100-diversion-header-support-per-rfc5806