Non-INVITE Transaction Issues Robert Sparks dynamicsoft

The Race Condition 64*T1 UAC UAS Timeout Request Response

The Race Condition UAS believes it responded in time UAC and UAS have different ideas of the result of the transaction UAS has no way to know how much its transaction has been offset from the UAC Each proxy makes the race easier to lose 64*T1 UAC UAS Timeout Request Response RESULT: UAS Non-INVITE transactions must complete immediately!

408 is Not Useful 64*T1 UAC UAS Timeout Request 408 Request Timeout

408 is Not Useful 64*T1 UAC Proxy Request 408 Proxy UAS Request 408

408 is Not Useful 64*T1 UAC Proxy Request 408 Proxy UAS Request

Non-INVITE Timeouts Doom Forking Proxies 64*T1 UAC UAS1 Request 408 Proxy UAS2 415 UAS2’s failure to respond forces both proxies to lose the race 415

Failure to Respond Gets You Blacklisted RFC 3263 discusses moving to next SRV on a no-response timeout (or explicit transport failure) Non-INVITE can’t use next SRV on this request – transaction is already over If failure isn’t cached (address temporarily blacklisted), next request is doomed to the same failure.

Non-INVITE Provisional Responses Arguments for Banning –Wasteful since transaction must complete immediately –(Early) provisionals harm recovery from lost final responses Arguments Against –No response causes blacklisting –Losing the race is the same as not responding at all Should they be banned?

Proposals Proposal A –Make minor changes to use of current Non-INVITE transaction Proposal B –Reform the Non-INVITE transaction to allow it to pend indefinitely

Proposal A 1.Disallow non-100 provisionals 2.Disallow 100 Trying before Timer E reaches T2 3.Encourage 100 Trying if no final response after Timer E reaches T2 4.Disallow 408 to non-INVITE requests 5.Absorb late non-INVITE responses

Proposal A 1.Disallow non-100 provisionals 2.Disallow 100 Trying before Timer E reaches T2 3.Encourage 100 Trying if no final response after Timer E reaches T2 Prevents blacklisting Doesn’t harm lost final response recovery Doesn’t allow reliable provisional responses

Proposal A 4.Disallow 408 to non-INVITE requests Currently they waste network 5.Absorb late non-INVITE responses Don’t statelessly forward after the transaction times out

Proposal B Allow Non-INVITEs to pend (no timer F) Allow CANCEL ACK is not needed Backwards safe

Contrast Proposal A –Removes waste from the network –Improves recovery from a failed node –UAS NI transactions still have to complete immediately or risk losing the race –Does not address proxy doom Proposal B –408s become useful again –Relieves proxies from timeout doom –Still need to address harmful provisionals for UDP Either deprecate UDP or take Proposal A 1-3