I am using Session Manager to integrate with a SIP IVR.
Call Flow = CM to Session Manager to SIP IVR
When backend failures occur on the IVR, it responds to Session Manager with a SIP response code of '500 Server Internal error'. I have configured backup Entities with appropriately ranked Routing Policies to handle these events. However, currently Session Manager will proxy the 500 Server Internal error back to CM rather than continue through the redundant routing policies.
Session Manager documentation states: "that if any 4xx (except 422, 423, 484), 500, 501, 502, 503, 504, 603, or 606 response is received, Session Manager provides alternate routes. In the case of a 408, 500, 501, 502, 503, 504, 603, or 606 response, Session Manager provides alternate routes to the next resolved IP address or entity link."
When the SIP IVR responds with a SIP response code of 480 Temporarily Unavailable, Session Manager does route the call through the configured redundant routing policies configured.
Am I misinterpreting the documentation to expect the same processing on a 480 & 500 response code?
Call Flow = CM to Session Manager to SIP IVR
When backend failures occur on the IVR, it responds to Session Manager with a SIP response code of '500 Server Internal error'. I have configured backup Entities with appropriately ranked Routing Policies to handle these events. However, currently Session Manager will proxy the 500 Server Internal error back to CM rather than continue through the redundant routing policies.
Session Manager documentation states: "that if any 4xx (except 422, 423, 484), 500, 501, 502, 503, 504, 603, or 606 response is received, Session Manager provides alternate routes. In the case of a 408, 500, 501, 502, 503, 504, 603, or 606 response, Session Manager provides alternate routes to the next resolved IP address or entity link."
When the SIP IVR responds with a SIP response code of 480 Temporarily Unavailable, Session Manager does route the call through the configured redundant routing policies configured.
Am I misinterpreting the documentation to expect the same processing on a 480 & 500 response code?
Comment