Subject: RE: [Sipping] HERFP work

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 13 Aug 2007 12:24:55 +0200

Hi John, 

>Sorry I didn't get up to speak to this during the session, 
>but I still have a hard time understanding why the 199 
>proposal addresses HERFP, even partially. The 199 response 
>just indicates that an early dialog has terminated, without 
>giving any reason. To me it addresses a different problem space.

I guess the question is: what really is the HERFP problem?

Some say that the HERFP problem is simply the fact that you are not
informed about a terminated dialog - and in that case 199 does solve the
problem.

However, others think that HERFP is much more than that. E.g. Rohan's
draft defines procedures which can be taken after the UAC has received
the indicateion of the terminted dialog.

But, again, the purpose of my draft is to simply indicate that a dialog
has been terminated. Maybe it can then be used to solve other problems,
but that is not purpose of the draft.

Regards,

Christer

> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:[email-masked]]
> > Sent: 27 July 2007 00:53
> > To: sipping
> > Cc: Mary Barnes
> > Subject: [Sipping] HERFP work
> > 
> > Folks,
> > 
> > today, in the SIPPING session, we agreed that the SIPPING WG should 
> > work on, at least, resolving the problem described in:
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-holmberg-sipping-199-02.txt
> > 
> > This problem is a subset of the more general HERFP problem, 
> which is 
> > not only concerned with how to provide the UAC with 
> information about 
> > the final error response generated by the UAS, but also with how to 
> > fix the problem reported by the final error response (e.g., 
> by sending 
> > a new request).
> > 
> > Here you have a few (already expired) individual drafts on HERFP:
> > 
> > http://www.watersprings.org/pub/id/draft-jbemmel-sipping-herfp
> > -solution-00.txt
> > 
> http://www.watersprings.org/pub/id/draft-jbemmel-herfp-solution-00.txt
> > 
> http://www.watersprings.org/pub/id/draft-mahy-sipping-herfp-fix-01.txt
> > http://www.watersprings.org/pub/id/draft-roach-sip-herfp-avoid
> > ance-00.txt
> > http://www.watersprings.org/pub/id/draft-rosenberg-sip-unify-00.txt
> > 
> > We need to decide whether it is enough to work on the problem 
> > described in draft-holmberg-sipping-199-02.txt or we should work on 
> > the more general HERFP problem.
> > 
> > Comments are welcome.
> > 
> > Thanks,
> > 
> > Gonzalo
> > SIPPING WG co-chair
> > 
> > 
> > _______________________________________________
> > 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
> > 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 13 Aug 2007 12:27:26 +0200

Hi, 

>Would like to remark that
>http://www.watersprings.org/pub/id/draft-jbemmel-sipping-herfp-solution
-00.txt
>is an evolution of
>http://www.watersprings.org/pub/id/draft-jbemmel-herfp-solution-00.txt,
so you can disregard the latter.
> 
>Also, RFC3326 (Reason header) mentions HERFP and discusses 
>the option of including a final error code in a provisional 
>response (using Reason). It could be used in combination with 
>the 199 proposal.

The 199 draft currently doesn't talk so much about what extra
information is carried, since we're still on the requirement stage, but
sending the final error code sure is something which could be done.

Regards,

Christer

> Elwell, John wrote:
> but I still 
> > have a hard time understanding why the 199 proposal 
> addresses HERFP, 
> > even partially. The 199 response just indicates that an 
> early dialog 
> > has terminated, without giving any reason. To me it addresses a 
> > different problem space.
> >
> > John
> >
> >> This problem is a subset of the more general HERFP 
> problem, which is 
> >> fix the problem reported by the final error response (e.g., by 
> >> sending a new request).
> >>
> http://www.watersprings.org/pub/id/draft-mahy-sipping-herfp-fix-01.tx
> >> t http://www.watersprings.org/pub/id/draft-roach-sip-herfp-avoid
> >> ance-00.txt
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 13 Aug 2007 23:08:05 -0400

inline.

> informed about a terminated dialog - and in that case 199 does solve the

The problem, as the acronym implies, is that if a request forks, and 
some of the UAS generate recoverable errors, the UAC will often not have 
a chance to retry since those errors are not propagated upstream towards 
the UAC. As an example, if A calls B and this forks to X and Y, and Y 
rings but X generates a 401, that 401 challenge will not be passed 
upstream and basically Y alone will ring.

Your draft is addressing one case of this, where the "recoverable error" 
is the 487 that is a consequence of these early dialogs being terminated 
by the CANCEL. Here, there is not really an error to recover from per 
se, but its basically the same problem - that the UAC does not see these 
error responses and thus cannot act on them.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   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: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 14 Aug 2007 08:44:22 +0200

Hi, 

>>>Sorry I didn't get up to speak to this during the session, but I 
>>>still have a hard time understanding why the 199 proposal addresses 
>>>HERFP, even partially. The 199 response just indicates that an early 
>>>dialog has terminated, without giving any reason. To me it addresses 
>>>a different problem space.
>> 
>>informed about a terminated dialog - and in that case 199 does solve 
>>the problem.
> 
>The problem, as the acronym implies, is that if a request 
>forks, and some of the UAS generate recoverable errors, the 
>UAC will often not have a chance to retry since those errors 
>are not propagated upstream towards the UAC. As an example, 
>if A calls B and this forks to X and Y, and Y rings but X 
>generates a 401, that 401 challenge will not be passed 
>Your draft is addressing one case of this, where the 
>"recoverable error" is the 487 that is a consequence of these early
dialogs being 
>terminated by the CANCEL.

The draft doesn't only cover 487 and dialogs being terminated by the
CANCEL. 199 can be sent for ANY error response terminating a dialog (and
the termination doesn't have to be triggered by a CANCEL).

If that is unclear in the draft I can try to fix it somehow.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 14 Aug 2007 08:16:21 +0100

Christer,

But HERFP generally arises when no early dialog is created, e.g., a 401
would normally be given without establishing an early dialog. I see 199
as addressing only a small fraction of the total HERFP problem space.

John 

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: 14 August 2007 07:44
> To: Jonathan Rosenberg
> Cc: Elwell, John; Gonzalo Camarillo (JO/LMF); sipping; Mary Barnes
> Subject: RE: [Sipping] HERFP work
> 
> 
> Hi, 
>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 14 Aug 2007 11:41:44 +0200

Hi, 

>But HERFP generally arises when no early dialog is created, 
>e.g., a 401 would normally be given without establishing an 
>early dialog. I see 199 as addressing only a small fraction 
>of the total HERFP problem space.

Correct.

However, as we have discussed, one option would be that the 199 is sent
by the UAS. So, technically a UAS (or, even a proxy) COULD send 199 even
if no early dialog has been established. 

But, as you say, that is currently not within the scope of the draft,
which focues on informing about terminated dialogs that have been
established.

Regards,

Christer

> forks, and 
> > >some of the UAS generate recoverable errors, the UAC will 
> often not 
> > >have a chance to retry since those errors are not 
> propagated upstream 
> > >towards the UAC. As an example, if A calls B and this 
> forks to X and 
> > >Y, and Y rings but X generates a 401, that 401 challenge 
> will not be 
> > >passed upstream and basically Y alone will ring.
> > > 
> > >Your draft is addressing one case of this, where the "recoverable 
> > >error" is the 487 that is a consequence of these early
> > dialogs being
> > CANCEL. 199 can be sent for ANY error response terminating a dialog 
> > (and the termination doesn't have to be triggered by a CANCEL).
> >

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 14 Aug 2007 12:57:49 +0100

Christer,

I think 199 when no early dialog is established would create an early
dialog at any UAC or dialog-stateful proxy that does not understand 199.
Seems to be counter-productive.

John

> Sent: 14 August 2007 10:42
> To: Elwell, John; Jonathan Rosenberg
> Cc: Gonzalo Camarillo (JO/LMF); sipping; Mary Barnes
> "recoverable

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 14 Aug 2007 14:05:00 +0200

Hi, 

>I think 199 when no early dialog is established would create 
>an early dialog at any UAC or dialog-stateful proxy that does 
>not understand 199.

Maybe not if you don't include a To tag. 

But, again, I haven't really thought about it that much, since the draft
focues on dialogs.

Regards,

Christer

> > >But HERFP generally arises when no early dialog is 
> created, e.g., a 
> > >401 would normally be given without establishing an early 
> dialog. I 
> > >see 199 as addressing only a small fraction of the total HERFP 
> > >problem space.
> > 
> > Correct.
> > 
> > by the UAS. So, technically a UAS (or, even a proxy) COULD send 199 
> > even if no early dialog has been established.
> >