Re: [Sipping] Possible Solution to HERFP

[Rohan Mahy <[e-mail]>]

On Jul 31, 2005, at 5:18, Jonathan Rosenberg wrote:
> Rohan,
>
> Thanks for revisiting this. I like the draft and think it has merit.
>
> In some sense, the approach is not far from another solution to herfp 
> which Jon P. has, inadvertently I think, proposed - that you disallow 
> retargeting and require redirect. If, instead of the proxy forking a 
> request to N destinations, it redirects with N contacts, each of which 
> is actually a gruu URI that routes to the instance which was to be the 
> target, you also end up eliminating the herfp problem. Your solution 
> is similar by having the proxy tunnel a "redirect" in the 130 
> response, but  you persist the original transaction. That allows the 
> proxy to retain control over the forking of the request, while giving 
> the UAC the ability to repair the failed branch.

thanks

> A litmus test for any herfp solution is whether it works for a 
> sequential ring kind of application (ring phone 1, then phone 2 after 
> 10s, then phone 3 after another 10) when phones 1 or two generate a 
> repairable error response. I believe your solution meets the litmus 
> test. Since the proxy still has the original transaction running, if 
> the "child" transaction to phone 2 times out after 10s (assuming phone 
> 2 had generated the repairable response), the proxy can cancel the 
> child transaction and sequence to the next branch of the original 
> transaction.

yes.

> I think the usage of response identity as the security mechanism here 
> makes no sense. If you want to authorize the 130, you should send the 
> original request with sips. I believe the desired property is that you 
> would trust a 130 sent by any proxy on the original request path.

while this might be a reasonable approach, what i was looking for was 
to only repair based on 130s from the domain to which you sent the 
original requests.

> As such, there would be no need for a client-initiated CANCEL in the 
> case of a mistrusted response, and this CANCEL was the source of the 
> problems discussed previously in this thread.

actually, the motivation for introducing the cancel is different.  If 
the proxy runs a timer for the branch (as you suggest later), the proxy 
needs to wait for the timer to expire before abandoning the branch and 
delivering a final response.  positive knowledge that UAC will repair 
the branch or not, is very valuable and contributes to a better user 
experience.

Adam suggested the use of a new method instead of reusing CANCEL.  I 
think this is a reasonable suggestion.

> I think a proxy generating a 130 also needs to set a timer, to deal 
> with the case that the client does not try to repair.

I'm not sure such a timer is needed in practice.  If the timer is 32 
seconds, it is quite likely that the proxy would have already abandoned 
the branch (or the entire call) and possibly sent a 408 (for an INVITE 
transaction) or a 480.

> In such a case, it could treat the branch on the original transaction 
> as if it had gotten a 487. This would allow the sequential forking 
> application litmus test above to still work in cases where the client 
> elects not to repair.

quickly treating the branch like a 487 if the UAC does not repair is 
important for the user experience of your forking litmus test.  I don't 
think this  achievable with a timer without falsely abandoning repaired 
branches.

> Like gruu, you need to discuss the validity and lifecycle maintenance 
> of these branch URI. I think that they remain valid only as long as 
> the original transaction remains active at the proxy. This would imply 
> that constructing such a branch URI is probably done by encoding the 
> outgoing branch ID into the user part of the URI. The domain part 
> would be constructed so that it routes to that proxy.

I really don't like the "creating a URI" terminology.  I am happy to 
discuss when these URI are useful and when they MUST be around.  As for 
creating and destroying anything, my prototype implementation doesn't 
"create" or "destroy" any URIs.   The proxy recognizes the URI type and 
checks if the response context and branch exist. Other implementations 
might explicitly create or destroy something which I am fine with, but 
I don't think it is helpful to describe the process using those terms 
in the text.

> What does the proxy do if the user cancels the original transaction? 
> Does the proxy CANCEL the children transactions?

yes

> I think it should. In a sense, the child transaction is a stand-in for 
> the failed branch, replacing it so that the branch sort-of exists 
> still, but with a separate set of transaction identifiers. As such, 
> anything that would cause the proxy to terminate the original branch 
> should terminate the child.

yes, for example a 2xx or 6xx terminates all the child branches.

thanks,
-rohan


> Thanks,
> Jonathan R.
>
>
>
> 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
>
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [e-mail]                              FAX:   [phone]
> http://www.jdrosen.net                         PHONE: [phone]
> http://www.cisco.com


_______________________________________________
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