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 one and only one Vendor, while Vendor can have many Connections that belong to it.

The following figure illustrates this concept:



Here you can see system which has 6 connections to 3 different vendors. Each connection represents separate SIP-PSTN gateway located in different places all around the world.


Connections


Connections are logical entries in the system representing destinations for sending calls to. For example connection can represent specific SIP-PSTN gateway in your network, another SIP softswitch that belong to your termination provider, some SIP IVR or 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 for sending outgoing calls to;
  • Username – username for the SIP digest authentication if required by the Connection destination;
  • Password – password for the SIP digest authentication if required by the Connection destination;
  • CLD Translation Rule – translation rule to be 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 Softswitch to limit number of simultaneous calls establishes to this particular Connection by the value of the Capacity parameter;
  • Use Media Relay – policy for using media relay (RTPProxy) when sending calls to this 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 are being sent from 5060 port, otherwise from one of the b2bua's 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 those codes is received from that Connection the Softswitch will stop hunting (i.e. it prevents switch from trying to connect call to the alternative Connection). For example, if a particular Connection is known to correctly report when PSTN destination number is busy by sending 486 Busy Here the parameter could be set to 486. Huntstop is applied to any SIP codes like 500, 486, also it works for 1xx SIP codes, like 180, 183 - this is recent change available starting from 5.0 Sippy version (© 2019)
  • Outbound proxy - it is new feature that allows to set specific outgoing IP and port in INVITE message (e.g. vendor connection IP), so that the INVITE packet will be sent to the defined <IP:port> in 'Outbound proxy' field, but the request URI field will contain the <IP:port> from 'Destination' field.
  •  Allowed RURI Params. - The new field connections.pass_ruri_params contains a comma separated list of parameter names to pass. For example if the 'user' parameter should be passed to vendor and 'test' parameter should be dropped in this INVITE:

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

           then the connections.pass_ruri_params should contain 'user'. And if both parameters should be passed then the connections.pass_ruri_params should contain 'user,test'.

  • Max CPS- maximum number of outbound call attempts per second for a connection
  • Blocked - if checked connection will not be used in routing
  • Random Call-Id - check to generate call ID instead of using one from inbound invite
  • Ignore LRN - do not perform LRN dipping
  • Reply Timeout, sec - the time that Sippy will wait for the 100 reply before trying next conenction
  • Outbound IP - source IP that will be used in outbound messages to vendor
  •  Enable Diversion - enables mentioned header, see https://support.sippysoft.com/solution/articles/3000061100-diversion-header-support-per-rfc5806
  •  From Domain - modifies IP in From field in invite to a vendor with some domain name, see
  •  Accept 3xx Redirects - check to accept and process 3xx responses, see 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 redirected call receives another 3xx response. In case of 300 Multiple Choices redirect the Redirect Depth Limit limits the maximum number of the hunt attempts.
  •  Privacy Mode - Replace CLI with a number received from caller in either P-Asserted-Identity or Remote-Party-ID header
    •  Off - neither number from P-Asserted-Identity, nor Remote-Party-ID headers would affect the CLI that is sent to vendor
    • P-Asserted-Identity - CLI would be replaced with the number from P-Asserted-Identity header. If CLI translation rule is configured on Connection, it will be applied to the number from P-Asserted-Identity before sending INVITE to vendor
    • Remote-Party-ID - CLI would be replaced with the number from Remote-Party-ID header. If CLI translation rule is configured on Connection, it will be applied to the number from Remote-Party-ID before sending INVITE to vendor
  • Use CLI As P-Asserted-Id  -Support For SIP Asserted Identity within Trusted Networks, see https://support.sippysoft.com/solution/categories/81138/folders/134069/articles/84156-support-for-sip-asserted-identity-within-trusted-networks-rfc-3325-
  •  Allowed RURI Params. -  a comma separated list of parameter names to pass. For example if the ‘user’ parameter should be passed to vendor and ‘test’ parameter should be dropped in this INVITE:
  • INVITE sip:21650011495@213.39.46.3;user=phone;test=value SIP/2.0
  • Asserted-Id Tr. Rule - translation rule which allows to edit the outgoing Asserted Identity. The translation rule is always applied to the Asserted Identity no matter whether it was received on the incoming call leg 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 - Tr. Rule 'Diversion Header Tr. Rule' Switch operator can also set the Diversion Header Tr. Rule in order to change the Diversion number according to the Vendor requirements. see https://support.sippysoft.com/solution/articles/3000061100-diversion-header-support-per-rfc5806