Re: [Sipping] Possible Solution to HERFP

[Rohan Mahy <[e-mail]>]

On Jul 8, 2005, at 22:09, Adam Roach wrote:

> 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.

I was just trying to be compliant with the existing timers from RFC 
3262 Section 3.  I agree they are not especially useful for most 
reliable provisionals

> ---
> 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.

currently RFC 3261 requires an offer or an answer to be in the first 
reliable message after an INVITE.  If we can change the behavior in a 
reasonable way then great, but right now that is best behavior that I 
could come up with that doesn't violate the core spec.  suggestions are 
welcome here.

> ---
> 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.

would you be satisfied if the 130 response was only allowed to be sent 
for branches that won't fork?

> ---
> 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.

both good points.

thanks,
-rohan

>
> /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