Re: [Sipping] Possible Solution to HERFP

[Jonathan Rosenberg <[e-mail]>]

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.

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.

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

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

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.

What does the proxy do if the user cancels the original transaction? 
Does the proxy CANCEL the children transactions? 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.

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