Re: [Sipping] Possible Solution to HERFP

[Adam Roach <[e-mail]>]

Looks good overall.

Preliminary comments:

---
60 seconds seems an awfully large threshold for retransmission of 
unacknowledged 130s. Wouldn't something more like 4 seconds be more 
appropriate? It seems unlikely that INVITE requests will pend for long 
enough for a 130 response to be retransmitted -- in which case, I'd just 
as soon not have to run another timer.
---
With reliable responses, the document requires the proxy to include an 
offer or an answer in the 130. I suspect that you'll encounter a lot of 
times in which this simply isn't possible. The first that comes to mind 
is S/MIME encrypted bodies. I also shudder to think that I'll have to 
deploy SDPng (or any alternate session description format) in the middle 
of my network before clients can make use of it. I suspect we can get by 
without the offer or answer for 130s.
---
The sending of CANCELs to branches which are to be abandoned seems like 
it might be problematic. I could just be remembering some subtle 
protocol issues incorrectly, though.

Let's say you have a UAC (supporting herf), which sends a request to 
proxy A. Proxy A forks the request to Proxy B and UAS1. Proxy B forks 
the request to UAS2 and UAS3. UAS2 responds with a 401. Following the 
procedure you outline, Proxy B then sends a 130 to Proxy A. Proxy A then 
forwards this 130 to the UAC. The UAC doesn't have credentials for the 
indicated realm, so it sends a CANCEL to the URI indicated in the 
Contact header field of the 130. Proxy A sees this CANCEL, and matches 
it to the pending response context (with branches to UAS1 and Proxy B). 
Consequently, Proxy A returns a 200 to the CANCEL and generates its own 
CANCEL requests for its two client transactions.

Even if Proxy B is able to deduce what is going on here (and I don't 
think it can), UAS1 has now become unreachable.
---
And a couple of tiny nits that you can completely ignore:

    * I think I would call 130 something more like "Branch Error"
      instead of "Reparable Error." Most errors conveyed won't be reparable.

    * Appendix A is certainly useful for describing the problem, but I
      can already imagine the confused emails on the sip implementors
      list asking about the 155 error response code, and the use of
      COMET. I would suggest removal of section A.2.

/a


Rohan Mahy wrote:

> Hi Folks,
>
> I just submitted a new individual I-D that describes a possible  
> solution to the Heterogeneous Error Response Forking Protocol.  Until  
> it appears in the archives, you can find it here:
>
> https://scm.sipfoundry.org/rep/ietf-drafts/rohan/herf-fix/draft-mahy- 
> sipping-herfp-fix-00.txt
> https://scm.sipfoundry.org/rep/ietf-drafts/rohan/herf-fix/draft-mahy- 
> sipping-herfp-fix-00.html
>
> thanks,
> -rohan
> (as an individual)
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP