Subject: [Sipping] Possible Solution to HERFP

From: Rohan Mahy <[email-masked]>
Date: Fri, 8 Jul 2005 19:41:51 -0700

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

---

From: Adam Roach <[email-masked]>
Date: Sat, 09 Jul 2005 00:09:52 -0500

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

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 8 Jul 2005 22:53:59 -0700

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

> 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

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

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

>      COMET. I would suggest removal of section A.2.

both good points.

thanks,
-rohan

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 9 Jul 2005 11:10:57 +0200

Hi Rohan,

Section 3 picture at the end: what happens if UAS1 sends some provisional 
response (with a to-tag) before sending the 415? If the proxy generates a 
to-tag of its own for the 130, wouldn't the UAC get confused?

Jeroen

----- Original Message ----- 
From: "Rohan Mahy" <[email-masked]>
To: "'sipping' WG" <[email-masked]>
Cc: "Rohan Mahy" <[email-masked]>
Sent: Saturday, July 09, 2005 4:41 AM
Subject: [Sipping] Possible Solution to HERFP

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

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 9 Jul 2005 03:00:30 -0700

On Jul 9, 2005, at 2:10, Jeroen van Bemmel wrote:

> Hi Rohan,
>
> Section 3 picture at the end: what happens if UAS1 sends some 
> provisional response (with a to-tag) before sending the 415?

Why would UAS1 send any provisional response (other than a 100 Trying) 
before figuring out there was an error?  I've never seen an 
implementation do this, and the spec is pretty clear that you 
immediately send these error before you get the the processing stage 
where you would normally send a 18x.

> If the proxy generates a to-tag of its own for the 130, wouldn't the 
> UAC get confused?

are you asking this in general, or only after the UAS sent its own 
to-tag?

thanks,
-rohan

> Jeroen
>
> ----- Original Message ----- From: "Rohan Mahy" <[email-masked]>

---

From: Adam Roach <[email-masked]>
Date: Sat, 09 Jul 2005 11:04:36 -0500

Rohan Mahy wrote:

>> 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 think that's a non-normative recommendation -- and one which we have 
good reason to second-guess for something like HERFP processing.

>
>> ---
>> 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.
>
>
> could come up with that doesn't violate the core spec.  suggestions 
> are welcome here.

I might be missing the lore, but my reading of the first two bullets in 
the rules regarding offer/answer is:

    * The initial **OFFER*** must be in either an invite or in the first
      reliable non-failure message.
    * If the initial offer is in in invite, the answer must be in
      ***A*** reliable non-failure message.

Thinking through this, it appears place a requirement on proxies 
supporting herf to send offers in reliable provisionals if the invite 
didn't contain one -- and I think that's fine. However, it doesn't seem 
to require placement of an answer in the *first* reliable non-failure 
message, simply in one of them (presumably before the transaction succeeds).

Given this reading, I could build a client compliant with 3261 and 3262 
that, upon receipt of an INVITE with SDP, sent its first "180 Ringing" 
message reliably without SDP, and then followed up later with a reliable 
180 containing SDP. If, for some reason (e.g. the user presses a "do not 
disturb" button), the transaction ends before the second 180 is sent, 
then no answer to the offer ever crosses the wire.

[I have one further response to the cancel issue, but have run out of time]

/a

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 9 Jul 2005 18:49:45 +0200

>> response (with a to-tag) before sending the 415?
>
> before figuring out there was an error?  I've never seen an implementation 
> do this, and the spec is pretty clear that you immediately send these 
> error before you get the the processing stage where you would normally 
> send a 18x.
>

Well, I could think of the following scenario:

1. INVITE
2. proxy forks
3. an UAC receives: 100
4. 180 ringing
5. User presses 'cancel' (does not want to be disturbed) -> 486 Busy here 
[ maybe some implementations would send 603 decline instead though ]

You could argue that 486 is not a repairable error. In the draft you mention 
"400-class or 500-class response other than a 503, 487, or 408" as 
repairable responses that should trigger a 130, aren't there more cases that 
can potentially cause problems?
Perhaps it would be good to explicitly list those codes that are classified 
as 'repairable', and consider everything else as non-repairable. In 
particular, I think codes in the 4xx-5xx range that are currently undefined 
should be treated as unrepairable.

I am not sure if it would be a problem if the UAC received 2 to tags, 1 from 
the UAS (or UAC) and one from the proxy. If so then perhaps you could 
specify that in case a provisional response other than trying was received 
on the branch, then 130 should not be sent

>> If the proxy generates a to-tag of its own for the 130, wouldn't the UAC 
>> get confused?
>
> are you asking this in general, or only after the UAS sent its own to-tag?
>

I'll admit I didn't give it much thought yet but a question popped up about 
the case where the UAS would send a provisional response with its own 
to-tag, which would create an early dialog at the caller. The 130 from the 
proxy would generate a second early dialog, what happens to them?

I have a second question regarding section 5 : client should send CANCEL to 
acknowledge reception of the 130. Normally CANCEL should have the same 
request URI as the original request, so this usage of CANCEL seems a bit out 
of the ordinary to me. Could an ACK not be used instead?

For my understanding: if the proxy would generate a final response for each 
repairable error instead, each time generating a new to-tag, then that would 
require modifications to the UAC transaction state machine, right? 
(exception for final error code xxx)

>>> solution to the Heterogeneous Error Response Forking Protocol.  Until it 
>>> appears in the archives, you can find it here:
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Jul 2005 09:24:18 -0400

Jeroen van Bemmel wrote:

> I have a second question regarding section 5 : client should send CANCEL 
> to acknowledge reception of the 130. Normally CANCEL should have the 
> same request URI as the original request, so this usage of CANCEL seems 
> a bit out of the ordinary to me.

Yes, this was bothering me too. It is a new situation, because the proxy 
is acting as a UAS for the contact in the 130, so *maybe* we can make an 
exception in this case. But before doing that we need to investigate all 
the ugly things that might happen. It seems like cases involving 
multiple levels of forking might be troublesome.

> Could an ACK not be used instead?

ACKs aren't used with 1xx responses, so this would also be out of the 
ordinary.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 11 Jul 2005 11:52:22 -0500

> sipping-herfp-fix-00.html

Rohan:

Interesting approach to the problem.  After a quick reading, it
strikes me that a long time ago, we had a SIP mantra that was oft
repeated: "Every transaction completes independent of others."

Did we break this mantra?  In Figure 4, there are two INVITEs
leaving the UAC, the second in response to the 130.  However,
there is only one final response coming back to the UAC (the
200 OK).  Since the draft states that the original INVITE request
is unaffected by the new request, it would seem that the UAC
will wait for another final response to balance out the original
request?

Before proposing any solutions, wanted to make sure that we do
indeed have a dangling INVITE problem...

Thanks,

- vijay
-- 
Vijay K. Gurbani, Ph.D.  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 11 Jul 2005 13:21:34 -0700

Hi Vijay,

> will wait for another final response to balance out the original

I don't think we broke that mantra.  The original INVITE request still 
needs to receive the "best final response" from the proxy.  If the UAC 
sent INVITE requests to repair any of the branches, the target-set just 
uses 487 instead of the actual 4xx or 5xx for the branch for the 
purpose of best-response processing.  A 2xx or 6xx will always win the 
best-response war, and hopefully most 4xx responses will win instead of 
a 487.

thanks,
-rohan

> Vijay K. Gurbani, Ph.D.  
> vkg@{lucent.com,research.bell-labs.com,acm.org}

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 11 Jul 2005 15:39:33 -0500

Rohan Mahy wrote:
> uses 487 instead of the actual 4xx or 5xx for the branch for the purpose 
> of best-response processing.  A 2xx or 6xx will always win the 

Rohan:

So if I understand you correctly, the original request from the
UAC will engender a 4xx (maybe a 487).  The net result is that
the UAC still gets two final responses corresponding to the two
requests it sent out.  Essentially, one way to look at this is
that the UAC is "forking serially" in response to the proxy
prodding it via a 130.

If so, we should make it clear in the document that the
transactional integrity is preserved in the face of a 130.

Thanks,

- vijay

---

From: Adam Roach <[email-masked]>
Date: Tue, 12 Jul 2005 10:27:26 -0500

> for branches that won't fork?

Either I misunderstand what you're suggesting here, or you misunderstood 
the use case I tried to describe.

Proxy B has no way whatsoever to know that Proxy A forked the request. 
It can't know about UAS1. I has no way to determine that sending a 130 
(and consequently triggering the UAC to send a CANCEL) will ruin the 
ability to contact UAS1.

In practice, I'm not sure why the UAC needs to explicitly cancel dead 
branches. The proxy that generated the 130 already considers the branch 
to have completed (you're creating a new response context for any 
INVITEs sent in response to a 130) -- so what action does the proxy take 
upon receiving the CANCEL?

/a

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 12 Jul 2005 10:53:14 -0700

On Jul 12, 2005, at 8:27, Adam Roach wrote:

>>> like it might be problematic. I could just be remembering some 
>>> subtle protocol issues incorrectly, though.
>>>
>>> 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.
>>>
>> would you be satisfied if the 130 response was only allowed to be 
>> sent for branches that won't fork?
>
>
> Either I misunderstand what you're suggesting here, or you 
> misunderstood the use case I tried to describe.
>

You are absolutely right that Proxy B doesn't know that Proxy A forked 
the request, but Proxy A knows that it sent the request to a SIP node 
with which it does not have a directly registered association.

We have several choices here:
1) Proxy A can redirect the UAC to Proxy B by sending a 130 with an 
embedded 300.
2) Proxy A just doesn't send a 130 for branches that are directly 
registered.

In general I think it is rather rare these days to have two forking 
proxies in a call, so if this proposal solves the herf problem when 
only one proxy forks and doesn't break anything (but still has the 
possibility of having herfp) when multiple proxies fork then i think we 
are in good shape.

> branches. The proxy that generated the 130 already considers the 
> branch to have completed (you're creating a new response context for 
> any INVITEs sent in response to a 130) -- so what action does the 
> proxy take upon receiving the CANCEL?

the problem is the the proxy still needs to form a best response.  If 
you explicitly CANCEL, you change the effective best response on the 
branch from whatever it was to a 487.  If you explicitly CANCEL, you 
insure that the best response isn't an error response from a branch 
that the UAC can't or won't repair.  The proxy will pick a best 
response from another branch that could have something more interesting 
(and repairable) to say.

thanks,
-rohan

---

From: Adam Roach <[email-masked]>
Date: Tue, 12 Jul 2005 18:12:50 -0500

Rohan Mahy wrote:

>>>> 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 
>>>> (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.
>>>
>>>
>>>
>> Proxy B has no way whatsoever to know that Proxy A forked the 
>> request. It can't know about UAS1. I has no way to determine that 
>> sending a 130 (and consequently triggering the UAC to send a CANCEL) 
>> will ruin the ability to contact UAS1.
>
>

Consider the case in which Proxy A does not know about the herf extension.

/a

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 18 Jul 2005 23:21:09 +0200

Rohan,

About the HERFP issue. I was not involved in earlier discussions, so I 
apologize if I am repeating something that was already said

What if HERFP was addressed similar to how a proxy handles multiple 401+407 
responses: all repairable errors are collected and returned as one final 
response ( "4xx multiple responses" with the proxy generating a to-tag). The 
UA could then retry as its sees fit. Each error returned in this way should 
include an address to use to contact that specific entity only. The response 
body would probably be a good place for this collection of mayhem

To address the potential long waiting for some ringing endpoints that block 
forwarding of repairable errors, the UAC could simply include an 'Expires' 
header in the original INVITE, and/or maybe a special 'HERFP timeout' value 
to tell the proxy to CANCEL ringing things and return the best final 
response(s) at that point instead.

To address 2xx responses from hiding other alternatives, the proxy could 
append information about the pending repairable errors to the 2xx response 
before forwarding (for this case perhaps some header would be better than in 
the body). That would give the UAC an opportunity to try those other 
options. If some other branches have not returned yet, perhaps the proxy 
could append a header stating that ( i.e. "Proxy-HERFP-Pending: 3" )

Regards,

Jeroen

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 18 Jul 2005 23:23:32 -0700 (PDT)

Hi Jeroen,

In order to get the best user experience, the proxy should not have to
introduce an artificial delay so that the UAC can get (and possibly act
on) a repairable error.  For example, if branch #4 is the best possible
contact to reach me, but it responds with a 401 or a 415 or a 420,
delaying this until the proxy has heard from all branches, even for a few
moments, prevents the UA from getting the "best" branch.

thanks,
-rohan

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 19 Jul 2005 22:27:30 +0200

About the issue with multiple forking proxies:

A proxy is only allowed to fork if it is responsible for the domain 
specified in the request URI. So unless proxy A in the below case forks and 
modifies the request URI's domain to that of proxy B, the multi-proxy case 
should be rare and perhaps even be considered as a case of misconfiguration?

JvB

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 19 Jul 2005 23:14:09 +0200

> ACKs aren't used with 1xx responses, so this would also be out of the 

I was thinking about the proxy sending a final response (perhaps with no 
to-tag) instead of the 130, then the UAC could send an ACK as usual which 
the proxy could use as a signal to exclude that branch from consideration as 
a 'best response'. This would probably require a change to the UAC 
transaction state logic, i.e. not only be prepared to receive multiple 2xx 
responses but also multiple of such not-quite-final responses. To avoid such 
a change a code in the 2xx range could be chosen, but that seems not right 
semantically (unless you consider it a success to have located a repairable 
responder)

About the new INVITE that is supposed to fix the repairable error: should 
you not make sure that it follows the exact same path as the original, 
avoiding forks along the way? What if the proxy would form the Contact 
header with a list of Route headers corresponding to the path calculated 
from the INVITE it got originally, possibly extended with a Route entry that 
points to the UAS that responded with an error? I think this would make sure 
that any forking proxies along that path don't try their forking trick 
again, making the fix very targeted

Regards,

jeroen

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 19 Jul 2005 15:12:49 -0700

Hi Jeroen,

This would be a dramatic change to the INVITE transaction state machine 
which would certainly break many intermediaries.  I don't think that 
would be advisable.

thanks,
-rohan

On Jul 19, 2005, at 14:14, Jeroen van Bemmel wrote:

> I was thinking about the proxy sending a final response (perhaps with 
> no to-tag) instead of the 130, then the UAC could send an ACK as usual 
> which the proxy could use as a signal to exclude that branch from 
> consideration as a 'best response'. This would probably require a 
> change to the UAC transaction state logic, i.e. not only be prepared 
> to receive multiple 2xx responses but also multiple of such 
> not-quite-final responses. To avoid such a change a code in the 2xx 
> range could be chosen, but that seems not right semantically (unless 
> you consider it a success to have located a repairable responder)
>
> About the new INVITE that is supposed to fix the repairable error: 
> should you not make sure that it follows the exact same path as the 
> original, avoiding forks along the way? What if the proxy would form 
> the Contact header with a list of Route headers corresponding to the 
> path calculated from the INVITE it got originally, possibly extended 
> with a Route entry that points to the UAS that responded with an 
> error? I think this would make sure that any forking proxies along 
> that path don't try their forking trick again, making the fix very 
> targeted
>
> Regards,
>
> jeroen

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Jul 2005 18:21:03 -0400

Jeroen van Bemmel wrote:
> specified in the request URI. So unless proxy A in the below case forks 
> and modifies the request URI's domain to that of proxy B, the 
> multi-proxy case should be rare and perhaps even be considered as a case 
> of misconfiguration?

The situation you outline is not so unreasonable: Proxy for A forks to 
multiple contacts - some local phones plus another AOR B. Proxy for B 
forks to some additional phones.

This might happen if I have a vacation home with its own AOR and 
multiple phones, as well as a primary home with multiple phones. I might 
want to configure the proxy for my primary home to also ring immediately 
at my vacation home, so I always get calls promptly regardless of which 
place I happen to be.

	Paul

> JvB
> 
> 
> ----- Original Message ----- From: "Adam Roach" <[email-masked]>
>>>>>> 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.
>>>>>>
>>> You are absolutely right that Proxy B doesn't know that Proxy A 
>>> forked the request, but Proxy A knows that it sent the request to a 
>>> SIP node with which it does not have a directly registered association.
>>>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 20 Jul 2005 00:31:59 +0200

Hi Rohan,

We are talking about the INVITE client transaction state machines at 
intermediaries here, right? Would it really make a difference to them? 
300-699 takes them into the completed state, 2xx terminates the transaction. 
In either case they are already required to pass on responses with no 
matching transaction upstream statelessly (section 16.7)

What about the Route idea?

Jeroen

----- Original Message ----- 
From: "Rohan Mahy" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>
Cc: "Rohan Mahy" <[email-masked]>; "Paul Kyzivat" <[email-masked]>; 
"'sipping' WG" <[email-masked]>
Sent: Wednesday, July 20, 2005 12:12 AM
Subject: Re: [Sipping] Possible Solution to HERFP

> which would certainly break many intermediaries.  I don't think that would 
> be advisable.
>
> thanks,
> -rohan
>
>
>> the proxy could use as a signal to exclude that branch from consideration 
>> as a 'best response'. This would probably require a change to the UAC 
>> transaction state logic, i.e. not only be prepared to receive multiple 
>> 2xx responses but also multiple of such not-quite-final responses. To 
>> avoid such a change a code in the 2xx range could be chosen, but that 
>> seems not right semantically (unless you consider it a success to have 
>> located a repairable responder)
>>
>> from the INVITE it got originally, possibly extended with a Route entry 
>> that points to the UAS that responded with an error? I think this would 
>> make sure that any forking proxies along that path don't try their 
>> forking trick again, making the fix very targeted
>>
>> Regards,
>>
>> jeroen
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 20 Jul 2005 00:50:55 +0200

Right. That would leave us with 2 options:

1) Only enable HERFP protection on the first proxy, i.e. where the domain in 
the To header is equal to that of the request URI
2) Don't allow such holiday configurations, tell people to have their 
vacation phones register at home instead...

(2) would save you an intermediary hop which makes it even more promptly! 
But lacking the authority to enforce that, what about (1)?

Jeroen

----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>
Cc: "Adam Roach" <[email-masked]>; "Rohan Mahy" <[email-masked]>; 
"'sipping' WG" <[email-masked]>
Sent: Wednesday, July 20, 2005 12:21 AM
Subject: Re: [Sipping] Possible Solution to HERFP

>> and modifies the request URI's domain to that of proxy B, the multi-proxy 
>> case should be rare and perhaps even be considered as a case of 
>> misconfiguration?
>
> This might happen if I have a vacation home with its own AOR and multiple 
> phones, as well as a primary home with multiple phones. I might want to 
> configure the proxy for my primary home to also ring immediately at my 
> vacation home, so I always get calls promptly regardless of which place I 
> happen to be.
>
> Paul
>
>> JvB
>>
>>

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 19 Jul 2005 16:16:15 -0700

Hi Jeroen,

Rather than design on the fly on the SIP WG mailing list, I suggest if 
you have additional ideas about how to solve HERFP, you instead write a 
draft explaining how your proposed mechanism works.  The action of 
writing such a proposal usually uncovers a large number of problems.  I 
have abandoned what I thought was a "great idea" after writing a draft 
explaining the idea uncovered fatal flaws.  Even when I have an idea 
that works well, I usually uncover new aspects I had not specified or 
understood.

On Jul 19, 2005, at 15:31, Jeroen van Bemmel wrote:
> intermediaries here, right?

well, i was actually thinking of the UAC state machine, but it would 
affect the intermediaries as well.

> Would it really make a difference to them? 300-699 takes them into the 
> completed state,

if you send a final response to indicate a recoverable error, there is 
no way to forward another response later from another branch (for 
example a 200).

> 2xx terminates the transaction. In either case they are already 
> required to pass on responses with no matching transaction upstream 
> statelessly (section 16.7)

forwarding non-matching responses was deprecated with the approval of 
draft-sparks-sip-nit-actions

> What about the Route idea?

most UAs that I know will reject a request if there are any Routes left.

thanks,
-rohan

> Cc: "Rohan Mahy" <[email-masked]>; "Paul Kyzivat" 
> <[email-masked]>; "'sipping' WG" <[email-masked]>
>> This would be a dramatic change to the INVITE transaction state 
>> machine which would certainly break many intermediaries.  I don't 
>> think that would be advisable.
>>
>> thanks,
>> -rohan
>>
>>
>>>> ACKs aren't used with 1xx responses, so this would also be out of 
>>>> the ordinary.
>>>>
>>>
>>> I was thinking about the proxy sending a final response (perhaps 
>>> with no to-tag) instead of the 130, then the UAC could send an ACK 
>>> as usual which the proxy could use as a signal to exclude that 
>>> branch from consideration as a 'best response'. This would probably 
>>> require a change to the UAC transaction state logic, i.e. not only 
>>> be prepared to receive multiple 2xx responses but also multiple of 
>>> such not-quite-final responses. To avoid such a change a code in the 
>>> 2xx range could be chosen, but that seems not right semantically 
>>> (unless you consider it a success to have located a repairable 
>>> responder)
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Jul 2005 19:50:58 -0400

Jeroen van Bemmel wrote:
> 1) Only enable HERFP protection on the first proxy, i.e. where the 
> domain in the To header is equal to that of the request URI

There really is no guarantee that the To header ever matches the R-URI, 
though it normally is. For instance, if I send an invite and receive a 
3xx in response, when I retry the R-URI will be the contact from the 3xx 
and the To will be unchanged, and not equal the R-URI.

> (2) would save you an intermediary hop which makes it even more 
> promptly! But lacking the authority to enforce that, what about (1)?
>

Well, something is better than nothing. But guessing which cases are 
"normal" and which are "abnormal" has a habbit of having limited success.

	Paul

> Jeroen
> 
> ----- Original Message ----- From: "Paul Kyzivat" <[email-masked]>
>>> specified in the request URI. So unless proxy A in the below case 
>>> forks and modifies the request URI's domain to that of proxy B, the 
>>> multi-proxy case should be rare and perhaps even be considered as a 
>>> case of misconfiguration?
>>
>>
>> multiple phones, as well as a primary home with multiple phones. I 
>> might want to configure the proxy for my primary home to also ring 
>> immediately at my vacation home, so I always get calls promptly 
>> regardless of which place I happen to be.
>>
>> Paul
>>
>>> JvB
>>>
>>>
>>>>>>>> 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 
>>>>>> sending a 130 (and consequently triggering the UAC to send a 
>>>>>> CANCEL) will ruin the ability to contact UAS1.
>>>>>
>>>>>
>>>>>
>>>>>

---

From: Adam Roach <[email-masked]>
Date: Tue, 19 Jul 2005 18:55:04 -0500

I think it's ridiculous to impose these kinds of artificial restrictions 
on the network architecture just for the purpose of re-using the CANCEL 
method to communicate that an already-failed branch is being abandoned. 
I think we have two possible approaches that are slightly less ugly than 
ruining perfectly valid use cases:

1) Define a new method that means, "I'm abandoning the branch identified 
by a specific URI."
2) Re-use UPDATE in some fashion to indicate that the branch is no 
longer of interest.

/a

Jeroen van Bemmel wrote:

>> The situation you outline is not so unreasonable: Proxy for A forks 
>> to multiple contacts - some local phones plus another AOR B. Proxy 
>> for B forks to some additional phones.
>>
>>>>>>> would you be satisfied if the 130 response was only allowed to 
>>>>>>> be sent for branches that won't fork?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> forked the request, but Proxy A knows that it sent the request to 
>>>>> a SIP node with which it does not have a directly registered 
>>>>> association.
>>>>>
>>>>> 1) Proxy A can redirect the UAC to Proxy B by sending a 130 with 
>>>>> an embedded 300.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 24 Jul 2005 16:00:40 +0200

Rohan,

OK, I will work on that. For clarification: you have not abandoned the HERFP 
fix draft, right?

In section 4.1 you define a repairable response as a '400-class or 500-class 
response other than a 503, 487, or 408'. Did you perhaps mean 403 Forbidden 
instead of 503 here?
And perhaps this range is too broad? e.g. consider the case where a called 
user presses 'cancel' on his phone to refuse an incoming call which 
generates a '486 Busy here'; it would be annoying when the phone rings 
again. Such "try again later" responses should IMO be communicated to the 
caller, but any Retry-After headers should be honored. And a 486 without a 
Retry-After should probably not result in a second attempt

Jeroen

----- Original Message ----- 
From: "Rohan Mahy" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>
Cc: "Rohan Mahy" <[email-masked]>; "Paul Kyzivat" <[email-masked]>; 
"sipping" <[email-masked]>
Sent: Wednesday, July 20, 2005 1:16 AM
Subject: Re: [Sipping] Possible Solution to HERFP

> Hi Jeroen,
>
> Rather than design on the fly on the SIP WG mailing list, I suggest if you 
> have additional ideas about how to solve HERFP, you instead write a draft 
> explaining how your proposed mechanism works.  The action of writing such 
> a proposal usually uncovers a large number of problems.  I have abandoned 
> what I thought was a "great idea" after writing a draft explaining the 
> idea uncovered fatal flaws.  Even when I have an idea that works well, I 
> usually uncover new aspects I had not specified or understood.
>
> if you send a final response to indicate a recoverable error, there is no 
> way to forward another response later from another branch (for example a 
> 200).
>
>> 2xx terminates the transaction. In either case they are already required 
>> to pass on responses with no matching transaction upstream statelessly 
>> (section 16.7)
>
>>>> change to the UAC transaction state logic, i.e. not only be prepared to 
>>>> receive multiple 2xx responses but also multiple of such 
>>>> with a Route entry that points to the UAS that responded with an error? 
>>>> I think this would make sure that any forking proxies along that path 
>>>> don't try their forking trick again, making the fix very targeted
>>>>
>>>> Regards,
>>>>
>>>> jeroen
>

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 24 Jul 2005 07:38:34 -0700

On Jul 24, 2005, at 7:00, Jeroen van Bemmel wrote:

> Rohan,
>
> OK, I will work on that. For clarification: you have not abandoned the 
> HERFP fix draft, right?
>
> In section 4.1 you define a repairable response as a '400-class or 
> 500-class response other than a 503, 487, or 408'. Did you perhaps 
> mean 403 Forbidden instead of 503 here?

no, I meant 503.

> And perhaps this range is too broad? e.g. consider the case where a 
> called user presses 'cancel' on his phone to refuse an incoming call 
> which generates a '486 Busy here'; it would be annoying when the phone 
> rings again.

Francois Audet already made a similar comment.  I'm not sure I want to 
enumerate all the response codes that are repairable, but I agree the 
486 is not repairable in the traditional sense.

note though that, a user pressing a button on a phone has a semantic 
closer to 603 Decline, but I understand that the user may want to 
trigger voicemail or an attendant or something.

thanks,
-rohan

> Such "try again later" responses should IMO be communicated to the 
> caller, but any Retry-After headers should be honored. And a 486 
> without a Retry-After should probably not result in a second attempt
>
> Jeroen
>
> <[email-masked]>; "sipping" <[email-masked]>
>> Rather than design on the fly on the SIP WG mailing list, I suggest 
>> if you have additional ideas about how to solve HERFP, you instead 
>> write a draft explaining how your proposed mechanism works.  The 
>> action of writing such a proposal usually uncovers a large number of 
>> problems.  I have abandoned what I thought was a "great idea" after 
>> writing a draft explaining the idea uncovered fatal flaws.  Even when 
>> I have an idea that works well, I usually uncover new aspects I had 
>> not specified or understood.
>>
>>> Would it really make a difference to them? 300-699 takes them into 
>>> the completed state,
>>
>> if you send a final response to indicate a recoverable error, there 
>> is no way to forward another response later from another branch (for 
>> example a 200).
>>
>>>>> branch from consideration as a 'best response'. This would 
>>>>> probably require a change to the UAC transaction state logic, i.e. 
>>>>> not only be prepared to receive multiple 2xx responses but also 
>>>>> multiple of such not-quite-final responses. To avoid such a change 
>>>>> a code in the 2xx range could be chosen, but that seems not right 
>>>>> semantically (unless you consider it a success to have located a 
>>>>> repairable responder)
>>>>>
>>>>> should you not make sure that it follows the exact same path as 
>>>>> the original, avoiding forks along the way? What if the proxy 
>>>>> would form the Contact header with a list of Route headers 
>>>>> corresponding to the path calculated from the INVITE it got 
>>>>> originally, possibly extended with a Route entry that points to 
>>>>> the UAS that responded with an error? I think this would make sure 
>>>>> that any forking proxies along that path don't try their forking 
>>>>> trick again, making the fix very targeted
>>>>>
>>>>> Regards,
>>>>>
>>>>> jeroen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 30 Jul 2005 23:18:50 -0400

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.

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

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 31 Jul 2005 15:38:04 +0200

Jonathan, Rohan,

I share your opinion on the merit / importance of this draft. Please find 
some comments inline

> Thanks for revisiting this. I like the draft and think it has merit.
[ snap ]
>
> 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.
>

Based on earlier discussions, an additional test is whether it works when 
there are other proxies in the path before the HERFP-solving proxy. The 
draft proposes to use a request URI that points at the HERFP-solving proxy, 
which means the repaired request may follow a different path than the 
original request. This could mean that the repaired request is missing some 
headers that would be inserted by those intermediate proxies that are now 
bypassed.

> 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 

I agree that the response identity makes little sense, but I am not sure if 
sips for the original request would solve anything either. Consider again 
the case in which the HERFP solving proxy comes after another proxy in the 
path, then the SIPS connection is only until that first proxy. Even though 
each point-to-point connection will use sips, the UAC has no control over 
which proxies are trusted beyond the first. What about the following 
alternatives:

1. The UAC could use sips for the repaired request to validate the identity 
of the proxy that sent the 130 (and refuse any 130 without a sips Contact)
2. The UAC could put a challenge for HERFP-solving proxies in the original 
request, causing the proxy to proof its identity in the 130

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

What if instead the proxy would take the branch with the repairable response 
out of consideration for its final response, and act as if nothing was 
received? Then if the UAC does not respond to the 130 eventually a 408 
timeout would be generated, without requiring an additional timer. This 
would also remove the need for a CANCEL, in essence the proxy will act as if 
the branch timed out unless the client responds. If the client responds too 
late, the branch will no longer exist and it will get a 481 call/transaction 
does not exist

Regards,

Jeroen van Bemmel