About SIP Register (aor) failover: Incase a sip trunk is deregistered, how can we force the inbound calls to be forwarded to a different dial-peer or a specific phone number instead of aor
Would termination next hop be the way to go about?
This is default behavior. Yeti will reroute call to other vendor if termination gateway is not available.
If you want to reroute call to other dialpeer of same vendor, this dialpeer should have other routeset discrimitator value.
Well, actually has to reroute via different term_vendor to a different number.
A bit more explanation could probably help here, Since these sort termination Gateways will be using AoR to terminate traffic, most of them would have dynamic ips and they could go offline and online anytime and when the term_gw goes offline, it should actually reroute to a different full e164 number based on term_gw status as a means of fail over Via different vendor and bill the customer account accordingly.
Therefore, setting up this reroute on term_gw, it should be relatively straight forward. Generally, with SIP Registration trunk, they have next hop is either routes to a term_gw2 if term_gw1 is offline or the next hop is to a sip uri
Here is an example:
DP: 613 --> Term_GW_Group1 -> Term_GW1 (AoR) (When Online) AOR = [SIP:61311111111@4.4.4.4:5060]
DP: 614 -> Term_GW_Group2 -> Term_GW2 (When Term_GW1 is offline) [SIP:61411111111@3.3.3.3:5060]
Where: 4.4.4.4 is the vendor ip 1 and 3.3.3.3 is vendor ip 2
But anyway, I will try routeset discrimitator and let you know
I couldn’t find much documentation on routeset discrimitator, what is a routeset discrimitator? How different is it from setting up a different dial peer that is a copy of an existing dialpeer with lower priority.
I have managed to test a dialpeer with or without routeset discrimitator, it functions the same way but the challenge I have is to bill the right vendor account without having to create dedicated dial-peer for every sip trunk term gateway. For now, It seems, every AoR gateway, would require a dedicated fail-over dial-peer terminating to vendor GW A while billing linked to a vendor’s account B. There seems to be no way to bill the account when a sip trunk gateway is offline.
This is how I have managed to get around so far:
1x fail-over dial-peer in a routing group of the sip trunks linked to a gateway A conditioned to match dst_prefix and rewrite_dst_result and send it out via linked gateway A while billing vendor Account B… Till this much, it works but the challenge here is also, how to bill vendor A…
The key objective here is similar to a call forward to a mobile or phone_number where the SIP trunk users pays for the call in case their termination gateway goes offline.
if there is any other way to get this setup, please let me know… your assistance would he highly appreciated.
Yeti will not reroute calls to dialpeer owned by same vendor and same routeset discrimitator. So routeset discriminator allows to enable rerouting between dialpeers of same vendor.
Actually I can’t understand your problem. Could you provide some details - CDR and Routing simulation results.
Looks like you are trying to build some class5 system on Yeti. Yeti is not designed for class5.
Actually we are not building class5 system on Yeti rather trying to incorporate a class5 feature into Yeti for the sake of business continuity especially with SIP REGISTER use cases.
It is also called Call Forward Unregistered (CFU) an advance feature, very useful especially with SIP Trunk Registrations. But, yes, you are right, it is a class 5 feature and it not something Yeti currently has but would be useful to have in future.
I will inbox you the routing simulation results and thanks for routeset discriminator explanation, it makes sense. You have been a great help so far 
I have attached an CFU article for better explanation but I am sure, you would already know it and cucm is c5 system.
hey Dmitry,
I have figured out a work around solution for the 480 Gateway not registered i.e to send the traffic back to the Yeti which gets re authenticated and translated to a different number and sent out to a different vendor’s gateway. By this way, we could authenticate the request based on customer’s DID or whatever method and translate it to a e164 which selects the appropriate DP and Vendor. (Customer and Vendors billing remains in line)…
- Primary Route : Carrier → LB → SEMS–>YETI → DP → SEMS–> UAC (Online)
- Secondary Route (UAC=CC 480): SEMS–> LB → SEMS–>YETI -->e164 → DP–>SEMS–>CARRIER
The above tested OK.
The beauty of Class4…
Let me know what you think