1 / 9

Fixing Heterogeneous Error Response Forking Problem (HERFP) for INVITE Transactions

Proposed solution to HERFP in INVITE transactions, addressing varied error responses and providing a method for UAC to handle errors effectively.

derekroberts
Download Presentation

Fixing Heterogeneous Error Response Forking Problem (HERFP) for INVITE Transactions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Proposed Fix to HERFP*(Heterogeneous Error Response Forking Problem) Rohan Mahyrohan@ekabal.com * for INVITE transactions

  2. Crux of HERFP • When a UAC sends an INVITE and it forks, the forking proxy only delivers the “best response” • if it gets a 4xx or 5xx, or a 3xx for which the proxy does not recurse, these responses don’t get back to the UAC until all other branches are exhausted • if you get multiple 3xx, 4xx, or 5xx responses, the UAC can’t predict which ones it will get • the UAC cannot use SIP negotiation to fix some otherwise repairable responses

  3. all 3xx redirects 401/407 Digest Challenges 402 Payment Required 405/501 Method not allowed (switch to MESSAGE) 406/415/488 Not acceptable media 413/513 Too big 416 Unsupported URI scheme (SIPS->SIP) 420/421 Option Tags 493 Undecipherable 422/423 Too Brief 429 Provide Referrer ID 494 Need Sec-Agree 505 Unsupported Version 580 Precondition Failure Not Repairable in this context 408 Timeout 487 Request Terminated 503 Unavailable 480 Temp Unavailable 486 Busy 484 Keep dialing 485 Ambiguous Some Repairable Responses

  4. The Proposal (in a nutshell) • For each failed branch, proxy generates a provisional response and a branch-specific URI • The provisional response (130) contains the original response in a sipfrag, and copies its To-tag. The Contact header in the 130 is the branch-specific URI with a preloaded To header (so Identity works). • The UAC sends a request to each branch-specific URI to either explicitly decline or repair the error • since branch-specific URIs route to the forking proxy, the proxy can still add and cancel branches from the original fork set (in serial or parallel) • The method works even if none of the UAS support the extension. Only the UAC and the proxy which forks.

  5. UAC Proxy UAS1 UAS2 | | | | |--INVITE-->| | | | |--INVITE-->| | | |--INVITE------------->| | |<-------------180-----| |<-----180--| | | | |<---415----| | | |----ACK--->| | |<-----130--| | | |--INVITE-->| | | | |--INVITE-->| | | |<---180----| | |<-----180--| | | | | | | | | | | | |<---200----| | |<---200 OK-| | | |----ACK--------------->| | | |--CANCEL------------->| | |<--------200 (CANCEL)-| | |<---------------487---| | |-----ACK------------->| | | | |

  6. Suggestions on the list that don’t work • Use a timer to decide if the UAC will repair a branch. This delays a final response unnecessarily. • “Just” have the UAS do something to prevent HERFP. The whole problem is that each UAS doesn’t have identical capabilities. Doesn’t fix HERFP, although you could maybe help a bit. Not the focus of this draft. • Send multiple final error responses or no final error responses for original branch. Breaks downstream proxies.

  7. Suggestions from the list that work • Currently the UAC sends CANCEL to convey it will not repair a branch. • That doesn’t always work (oops) • Adam Roach suggested a new method. • Bob Penfield suggested using BYE. • More aggressively trim the list of repairable errors. Discuss privacy implications. Provide guidance about why certain responses are useful and others are not (408, 503, etc..) • Change the name of the 130 response. Maybe “Embedded Error”? • Delete the appendix

  8. Other concerns from the list • What final response is sent for the original transaction? Still the best response, but all abandoned branches are considered as 487s. • PRACK and all the offer/answer machinery? Yes, its a lot of stuff to implement. Any suggestions? • Why not solve for non-INVITE transactions? It is a non-issue for SUBSCRIBE/NOTIFY. Other NITs outside a dialog are contraindicated by the NIT actions document. • What if you are forking more than once? If a HERF-aware proxy wants to fork outside the domain, send a 130 with an embedded 3xx. A HERF-unaware proxy is oblivious • The draft mentions response Identity (specifically integrity). Is this useful, needed, or a waste of time?

  9. What do we do with this? • Do people like the idea? • Is anyone willing to implement it? (Other than me) • Next Steps?

More Related