Subject: [cuss] draft-ietf-cuss-sip-uui-04 (SIP methods used)

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 2 Nov 2011 11:56:41 +0100

As far as I can find, the definitive text for which messages the User-to-User header field can appear in is as follows:

   The User-to-User header field can be present in INVITE requests and
   responses only and in BYE requests and responses.  Note that only
   end-to-end responses can be used, e.g. 1xx (excluding 100), 2xx, and
   3xx responses.

1)	For the INVITE method, is this initial INVITEs only or does this include reINVITE I have a vague feeling this reINVITE is needed because of the transfer scenarios but wanted to make sure.

2)	For the refer scenarios mentioned in the CUSS requirements document, I assume any inclusion is in the INVITE embedded within the REFER request - rather than in the REFER request itself.

Regards

Keith

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 02 Nov 2011 08:29:31 -0500

On 11/02/2011 05:56 AM, DRAGE, Keith (Keith) wrote:
> As far as I can find, the definitive text for which messages the
> User-to-User header field can appear in is as follows:
>

A bit orthogonal to Keith's main point of this email, but ... 3xx may
not always be an end-to-end response.  Proxies are allowed to recurse
on a 3xx in rfc3261, and many do.  So, UUIs in 3xx responses may not
reach the intended recipient if the proxy recurses.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Alan Johnston <[email-masked]>
Date: Wed, 2 Nov 2011 11:15:13 -0500

Keith,

You are correct in your statements below.  I suspect inclusion in a
re-INVITE would be necessary for some 3pcc scenarios as well.

- Alan -

On Wed, Nov 2, 2011 at 5:56 AM, DRAGE, Keith (Keith)
<[email-masked]> wrote:
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>

---

From: Alan Johnston <[email-masked]>
Date: Wed, 2 Nov 2011 11:17:39 -0500

Vijay,

You are also correct - RFC 3261 does allow a proxy to recurse on a 3xx
in certain conditions.  We can reword it so that this is not
confusion.  The intent is to not allow it in 100, 4xx, 5xx, and 6xx
responses which are, by definition, sent hop-by-hop.

- Alan -

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 2 Nov 2011 17:23:53 +0100

I would question whether we need it in 3xx at all.

If we think of the UUI being delivered between applications, even if recursion at a SIP proxy does not occur, surely the processing of a 3xx and generation of a new INVITE based on the Contact would take place at the SIP level, without necessarily revisiting the application.

So even if the 3xx did go end-to-end, it could well never reach the application at the originating user.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alan Johnston
> Sent: 02 November 2011 16:18
> To: Gurbani, Vijay K (Vijay)
> Cc: [email-masked]
> Subject: Re: [cuss] draft-ietf-cuss-sip-uui-04 (SIP methods used)
> 
> Vijay,
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 02 Nov 2011 11:31:08 -0500

On 11/02/2011 11:17 AM, Alan Johnston wrote:
> Vijay,
>
> You are also correct - RFC 3261 does allow a proxy to recurse on a
> 3xx in certain conditions.  We can reword it so that this is not
> confusion.

Alan: Perfect.  Thanks.

> The intent is to not allow it in 100, 4xx, 5xx, and 6xx responses
> which are, by definition, sent hop-by-hop.

Yes, I gathered as much; but just to be sure that there are no
ambiguities we should do some wordsmithing around 3xx.  Some
suggested text:

OLD:

NEW:

   The User-to-User header field can be present in INVITE requests and
   responses only and in BYE requests and responses.  Note that only
   end-to-end responses should be used, e.g. 1xx (excluding 100) and
   2xx.  SIP intermediaries can recurse on a 3xx response, so a User-
   to-User header field may not reach the intended recipient when
   using this class of responses.  4xx, 5xx, and 6xx responses have
   hop-by-hop semantics, thus should not be used to transport a
   User-to-User header field.

Please feel free to change as needed.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 02 Nov 2011 11:34:47 -0500

On 11/02/2011 11:23 AM, DRAGE, Keith (Keith) wrote:
> If we think of the UUI being delivered between applications, even if
> recursion at a SIP proxy does not occur, surely the processing of a
> 3xx and generation of a new INVITE based on the Contact would take
> place at the SIP level, without necessarily revisiting the
> application.
>

I think we are better off not making any such assumptions.

I can imagine a UI on a SIP User Agent such that the user permission
(or even an automaton permission) is sought before actually recursing.

In such a case, the information associated with the 3xx does go to
the TU layer.

Thanks,

- vijay

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 2 Nov 2011 17:37:40 +0100

But in my view it would also be equally valid for the 3xx to be received by the SIP layer, and a new INVITE request generated automatically using the data from the Contact and the original INVITE request (including UUI). As such the sender of a 3xx cannot assume that UUI is delivered, even if it reaches the original UA.

If we allow it, then I think this should also be reflected in the text.

Keith

> Vijay K. Gurbani
> Sent: 02 November 2011 16:35
> To: [email-masked]