Skip to content
FlySIPFlySIP Docs

SIP 3xx redirects

Some vendors answer an INVITE with a redirect instead of connecting the call: “try this address instead”. By default FlySIP treats a 3xx response like any other failure and hunts to the next routing entry. With Accept 3xx Redirects on the vendor connection, the switch follows the redirect itself and sends the call to the address in the Contact header.

How it works

Section titled “How it works”
  1. The switch sends the INVITE to a connection with Accept 3xx Redirects on (Advanced Parameters tab, SIP connections only; off by default).
  2. The vendor answers with a redirect that has a Contact header:
    • 301 Moved Permanently or 302 Moved Temporarily: the switch takes the first URI of Contact.
    • 300 Multiple Choices: the switch takes all URIs of Contact and sorts them by their q parameter, highest first. A URI without q counts as 1.0.
  3. The switch sends a new INVITE to the first URI. The username of the URI becomes the CLD, exactly as received: no translation rule is applied to it. The new leg gets the Call-ID of the original leg with -1, -2 and so on appended, or a random one with Random Call-Id.
  4. If that attempt fails, the switch tries the next URI of a 300 response. If the redirected destination answers with another 3xx, the switch follows that one too.
  5. Redirect Depth Limit (1 to 20, default 1) caps the number of redirect attempts for one routing entry: chained redirects and the URIs of a 300 response all count. When the limit is reached or the URIs run out, the switch continues with the next routing entry, as after any failure.

Every redirect attempt uses the timeouts of the original routing entry: the connection’s Reply Timeout and the route’s 1xx Timeout and 2xx Timeout, as if each URI were a separate entry. See Call timeouts. When a redirected attempt fails with one of the connection’s Huntstop SIP Codes, the call stops as usual.

Each attempt writes a vendor CDR with the original connection and the same termination route, so it is rated with the vendor’s price for the original prefix even if the new CLD has another prefix.

Screenshot "admin-panel/connection-advanced-parameters" has not been generated yet — see scripts/screenshots/screens.yml.

Key terms

Section titled “Key terms”
  • Connection — a route to a vendor (SIP host, port, protocol, codecs) used by routing to send calls.
  • Hunting — trying the next route after a failed attempt.
  • Termination route — a vendor’s price list of prefixes used to route calls to that vendor; stored as a destination set.
  • CDR — Call Detail Record: one row per call with time, duration, destination, cost and disconnect cause.

Common scenarios

Section titled “Common scenarios”

A vendor returns 300 with three gateways

Section titled “A vendor returns 300 with three gateways”

The vendor answers:

Contact: <sip:000111111111111@192.0.2.5>;q=0.99, <sip:111111111111@192.0.2.4>;q=1.00, <sip:299111111111111@192.0.2.6>;q=0.98

With Accept 3xx Redirects on and Redirect Depth Limit 3 or more, the switch tries 192.0.2.4 with CLD 111111111111 first, then 192.0.2.5 with 000111111111111, then 192.0.2.6 with 299111111111111. With the default limit 1 it tries only 192.0.2.4 and then moves to the next routing entry.

A vendor redirects calls to a third party you do not want to pay for

Section titled “A vendor redirects calls to a third party you do not want to pay for”

Leave Accept 3xx Redirects off. The 3xx then counts as a failure and the switch hunts to the next entry of the routing group.

Section titled “Related pages”