Subject: [stir] Caller ID changes

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 29 Jul 2013 22:32:02 +0200

Reading the drafts I see no reference to caller ID changes during a call. 
See http://tools.ietf.org/html/rfc4916

Does any solution in this potential wg need to consider these mid-call changes of a caller ID?

/O

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 29 Jul 2013 22:55:36 +0200

Yeah we basically assumed we couldn't expect Call-ID to be usable, along with many other SIP headers.

Sent from my iPhone

On Jul 29, 2013, at 10:32 PM, "Olle E. Johansson" <[email-masked]> wrote:

> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Dan York <[email-masked]>
Date: Mon, 29 Jul 2013 23:08:55 +0000

Olle,

>Does any solution in this potential wg need to consider these mid-call

Right now the focus is on getting out a solution as quickly as possible
that solves the fundamental issue of delivering a secure caller identifier
from the calling party to the recipient. I don't know that we have yet
explicitly ruled a mid-call change as "out-of-scope" but I suspect we
*will* do so in order to keep the focus tight and deliverable.

The other aspect of RFC 4916, the ability to provide an authenticated
identifier for the *called party* WAS stated to be out-of-scope in an
earlier discussion on the list (and I know this because I was the one who
raised the question).  Again, the focus is on getting a solution that
solves the one main problem and is something that can be deployed rapidly.

Items like a mid-call change or identifying the called party are, in my
opinion, good candidates for a "STIRbis" once the initial system is out in
use.

My 2 cents,
Dan

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 30 Jul 2013 07:19:52 +0200

> opinion, good candidates for a "STIRbis" once the initial system is out in
Isn't there a risk that you will get a call and as soon as the call is
answered, there will be a caller ID update sent to make it harder
to call back? 

The traces will of course be showing both caller IDs, but the users
will still be annoyed.

I don't really know how widely updates are supported by providers
and I guess this is different by country. I do know that Asterisk supports
this in a number of ways, but not RFC4916-style, because of requirements
from Germany.

/O