Subject: [BLISS] Use of Callee Capabilities for CCBS/CCNR support indication

From: "Alexeitsev, D" <[email-masked]>
Date: Wed, 21 Nov 2007 14:58:11 +0100

Hi,

Does any one aware of a possibility to transfer the callee capability
indication in an unsuccessful response? 

The callee capabilities mechanism could be an alternative for the
transfer of the CCBS possible indication, but it suffers from the lack
of contact header in the unsuccessful responses. For the CCNR it would
immediately work.

Greetings,
Denis Alexeitsev

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Nov 2007 10:25:01 -0500

> of contact header in the unsuccessful responses. For the CCNR it would 

The capabilities are conveyed as header parameters of the Contact header 
in the successful response, and indicate the capabilities of the UA with 
which you have established a session. If the request fails, then you 
don't return a Contact and so can't return capabilities.

The framework for callee capabilities and caller preferences assumes 
there are multiple potential targets that could have different 
capabilities. In that environment it is hard to imagine what would make 
sense to return as capabilities when a request fails, because you don't 
know which UA to return capabilities for.

To me this is an clear signal that callee capabilities are not the 
correct mechanism for what you are trying to do.

	Thanks,
	Paul

> Greetings,
> Denis Alexeitsev
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: [email-masked]
Date: Tue, 27 Nov 2007 15:43:08 -0500

From: Paul Kyzivat <[email-masked]>

In a non-forking environment, the (sole) destination's Contact does
get returned in failure responses, though.  And if we implemnted
HERFP, the same would probably be true.  But in the RFC 3261 model,
where the UAC only gets a response from one destination, there is no
way for the destination(s) to signal reliably that they support CC.

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 27 Nov 2007 21:04:26 +0000

Dale,

See below.

John 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 27 November 2007 20:43
> To: [email-masked]
> Subject: Re: [BLISS] Use of Callee Capabilities for CCBS/CCNR 
> support indication
> 
> 
> get returned in failure responses, though.
[JRE] How? The Contact header field is not specified for any 4xx/5xx/6xx
response except 485.

> And if we implemnted

---

From: [email-masked]
Date: Tue, 27 Nov 2007 16:48:06 -0500

From: "Elwell, John" <[email-masked]>

I've been assuming that the UAS does put a Contact header on its 4xx
response, and that the intermediate proxies propagate the Contact
header back.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Nov 2007 17:34:15 -0500

[email-masked] wrote:
> response,

Why?

Even if it was permitted, what possible value would it serve?

> and that the intermediate proxies propagate the Contact
> header back.

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 28 Nov 2007 13:50:41 -0600

> Sent: Tuesday, November 27, 2007 3:48 PM
> To: [email-masked]
> I've been assuming that the UAS does put a Contact header on 
> its 4xx response, and that the intermediate proxies propagate 
> the Contact header back.

I don't think we should take into account any possible solution that
does not at least comply with 3261. I don't know under what
circumstances this assumption was made, and am not trying to comment on
that in any way. However, we definitely should exclude this type of
'solution' from any BLISS documentation outcome for this feature for
this reason.

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 28 Nov 2007 13:53:26 -0600

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Tuesday, November 27, 2007 4:34 PM
> To: [email-masked]
> Cc: [email-masked]

Well, assuming that you know it's a non-forking environment (the
originator used the no-fork directive) I could theoretically see having
a GRUU in a contact header in a 4xx being used to re-attempt the session
to a particular user agent after presumably addressing the reason for
the 4xx response.

It's a pretty contrived situation though. Especially if the proxy is
deterministic in it's routing decisions given the absence of forking.