Subject: Re: [sipcore] #29: B2BUAs passing H-I through?, #28 UAC adds initial HI

From: Mary Barnes <[email-masked]>
Date: Fri, 10 Sep 2010 16:50:14 -0500

Dale,

There is text that says that a UAC can add History-Info in section
4.1, which is the text Hadriel refers to in the original issue.
   "Normally, UACs are not expected to include a History-Info header
in an initial
   request as it is more of a Proxy function; the main reason it is
   allowed is for B2BUAs who are performing proxy-like functions such as
   routing."

Issue #29 suggests this should to be stated normatively (as well as
including this in the UAS section). It seems to me that we can make
that a MAY strength. It's not clear to me that we need to add anything
to the proxy section for B2BUAs as I really don't want to get into
trying to define B2BUA behavior beyond what is absolutely necessary in
this document.

Also, note that your Issue #28 suggests that we should have the UAC
add the (initial) History-Info entry, which is what we had in 4244.  I
will revert the text back to the 4244 behavior for this one.

Thanks,
Mary.

On Fri, Sep 10, 2010 at 2:50 PM, Worley, Dale R (Dale)
<[email-masked]> wrote:
> ________________________________________
> From: [email-masked] [[email-masked]] On Behalf Of Hadriel Kaplan [[email-masked]]
>
> Since a B2BUA is a UAC and UAS, one might think it should follow the rules for a UAC and UAS in this draft, restarting/clearing the H-I on each side.
>
> What you really want is a sentence/para saying a B2BUA would follow the rules for a Proxy with regards to H-I for requests which it forwards, unless local policy says otherwise; while for requests it generates itself it should act as a UAC.  For example if it generates a dialog-creating INVITE due to receiving a REFER, it would act as a UAC per the 4424bis draft, but if it is merely forwarding a dialog-creating INVITE (i.e. generating one due to receiving one) then it should follow the rules for a Proxy and copy the received H-I and add an entry, etc.  Right?
> _______________________________________________
>
> Yes.  Or perhaps even more flexibly -- E.g., a B2BUA that is creating an INVITE due to receiving a REFER, but that continues a dialog "from the other side", might send the new INVITE with the H-I received well in the past, when the other side dialog was created.  But the main point is as you stated, as the text stands now, a B2BUA sending an INVITE is acting as a UAC and must reinitialize the H-I.
>
> Dale
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 17 Sep 2010 14:02:38 -0400

________________________________________
From: Mary Barnes [[email-masked]]

_______________________________________

Well, strictly speaking, a B2BUA isn't a proxy.  The behavior we want to enable is part of the UAC function of the B2BUA.  But it seems to me that we want to enable this behavior normatively, and describe it much more clearly.  The current text mentions it only in passing, and while "there is only one thing that it could mean", that is not a good specification.

Dale

---

From: Mary Barnes <[email-masked]>
Date: Fri, 17 Sep 2010 13:21:53 -0500

Dale,

I think you totally  missed my point. My suggestion is to add a MAY in
terms of UAC b2bua behavior, something like the following (removing
the text about "Normally,...,")
   In the case of a B2BUA implementation,
   a UAC MAY add the hi-entries received in the incoming request at the
   UAS to the subsequent outgoing request.

We cannot however mandate B2BUA behavior since there are no normative
specifications for B2BUA behavior.

Mary.