1. Proposed Fix to HERFP* (Heterogeneous Error Response Forking Problem) Rohan Mahy rohan@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. Some Repairable Responses 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

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?