Subject: Re: [Sipping] Possible Solution to HERFP

From: Rohan Mahy <[email-masked]>
Date: Tue, 2 Aug 2005 00:29:38 +0200

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 [email-masked] for questions on current sip
>> Use [email-masked] 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
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 2 Aug 2005 10:19:18 +0200

I think this a good solution to the problem, but I do have some thoughts.

1. Cancelling pending branch associated with 130 response

I also think that using CANCEL for terminating the pending branch will be
problematic. An intervening non-HERFP proxy will likly respond with 481 and
not forward the CANCEL. This could occur with the presence of an outbound
proxy, or Service-Routes.

The 130 response from the proxy is required to have a to-tag. This creates a
dialog between the UAC and the forking proxy. IAW 3261, this dialog can be
terminated with a BYE request. This can indicate to the proxy that the UAC
wishes to terminate the branch.

With regard to the to-tag, if the UAS had sent a provisional response with a
to-tag, the response included in the "message/sip" body would have the same
to-tag as in the provisional response. The UAC can use that tag to clean up
the early dialog. The proxy should generate its own to-tag in the 130
response to uniquely identify the dialog between the UAC and the proxy
(acting as UAS).

2. Race condition between UAC repair and remaining branches completing

I'm not sure if this has been covered, but what happens when all the
remaining branches receive a final response while the 130 is in transit to
the UAC. If one of those responses is a 503, the proxy would normally send
the "best" final response to the UAC. Is that what it should do? Or should
it wait until the 130 has been acknowledged? I'm thinking it should wait for
the 130 acknowledgement.

Also, there is the case where multiple branches receive repairable errors at
about the same time. Does the proxy send a 130 for additional branches when
it has an outstanding 130 for a previous branch? I would say yes, since the
UAC may be able to repair some errors and not others.

In any event, I think there does need to be some sort of timer on the 130
acknowledgement to cover the case when all branches have completed but there
is one or more outstanding 130s. The primary reason is that the server
transaction needs to be terminated when the proxy sends the final response
(IAW 3261), and the pending 130s are really part of the server transaction.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]