Subject: RE: [Sipping] Internet draft on missed calls / msgs notification

From: "Francois Audet" <[email-masked]>
Date: Tue, 27 Sep 2005 14:02:01 -0500

I think the key point is Dave's point about the ability to
see missed calls on a variety of devices that may not have
received the INVITEs in the first place.

Today, missed calls are logged individually at the devices themselves 
(using P2P, to use Henry's terminology). 

If one of those devices is "not always on", like a PC client for
example,
or a mobile device, it will not be able to see the "missed calls" that 
landed elsewhere (on the desk phone at work, or on a home phone or 
whatever).

The "cost of server" argument is interesting, but it really depend
on the enviroment you are in. In some environments, like an Enterprise 
for example, the cost of the "server" may not be an issue. And having 
the ability to see "all missed calls" may be quite important.

I think a missed call package is a decent idea.

_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 27 Sep 2005 22:41:00 +0200

Perhaps it would be an idea to come up with a list of such explicit 
requirements, and add that to the draft under section 3 (which now has 3 
lines describing the problem). So far we have:
- it MUST be possible to receive information on calls on any endpoint
- the list of calls for a given identity SHOULD be complete, meaning it 
SHOULD include information on calls placed while no endpoints were 
registered for that user, while one or more endpoints were busy, ....[ more 
cases here ]
- the call information MUST be treated as privacy sensitive, it SHOULD NOT 
be shared over an unsecure channel and integrity mechanisms SHOULD be used

I would also suggest to extend the scope from "missed calls" to "calls" or 
"call log", including calls that were answered (but perhaps on a different 
endpoint than used for viewing the information). It should also be 
considered how information from different sources is merged (e.g. forked 
calls, 1 endpoint reports 'busy' and the other accepts, how is the call 
logged?)

Perhaps a discussion on giving others permission to view your calls (e.g. a 
secretary on behalf of her boss) would be in place

Regards,

jeroen

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Sep 2005 17:45:00 -0400

Jeroen van Bemmel wrote:
> registered for that user, while one or more endpoints were busy, ....[ 
> more cases here ]
> - the call information MUST be treated as privacy sensitive, it SHOULD 
> NOT be shared over an unsecure channel and integrity mechanisms SHOULD 
> be used
> 
> I would also suggest to extend the scope from "missed calls" to "calls" 
> or "call log", including calls that were answered (but perhaps on a 
> different endpoint than used for viewing the information). It should 
> also be considered how information from different sources is merged 
> (e.g. forked calls, 1 endpoint reports 'busy' and the other accepts, how 
> is the call logged?)

I agree.

And calls that were placed, rather than received, are also of interest. 
Again there is the value of seeing a consolidated list of all for the 
AOR, rather than just those placed by a particular UA.

	Paul

> Perhaps a discussion on giving others permission to view your calls 
> (e.g. a secretary on behalf of her boss) would be in place
> 
> Regards,
> 
> jeroen
> 
> ----- Original Message ----- From: "Francois Audet" <[email-masked]>
> To: <[email-masked]>

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Sep 2005 19:37:25 -0500

> I think a missed call package is a decent idea.

I've been pondering something similar in the scope of residential  
primary line service definition in another SDO, and one of the  
approaches that has been suggested is the use of a "network event  
package" that could do things like tell a subscriber:

* A call was sent to your AOR but answered at another Contact:

* A call was sent to your AOR, but since you have diverted all calls  
to voice-mail, it was sent there.

* A call was sent to your AOR as a result of a forwarding operation  
applied to a transferred call in a partner network, was rejected from  
your voice mail server for lack of a compatible codec, and has been  
diverted to a small pub in East Anglia that we thought you might be at.

* A call was sent to you AOR, and forked to your contacts, one of  
which replied with a "busy everywhere" response causing us to reject  
the call. Perhaps you should check into it.

That is to say, perhaps such a package could reflect both 1)  
processing decisions made by a serving proxy for an AOR in response  
to a request, 2) history information contained in that request,  
especially if such information is used in the processing of the  
request, and 3) history information gleaned from processing of the  
request in other nodes on alternate paths "downstream" from the proxy.

So in addition to being able to give a you a missed call summary (ala  
the old Teltier 2g application by that name), this package could also  
issue the logical equivalent of the "splash rings" that Class 5  
switches send when they've diverted a call away from a subscriber  
line as a result of call forwarding. Or it could tell employee Bob in  
the call center that fellow employee Alice just took a call, and that  
she's taken the last three calls for the call center, and perhaps he  
should finish his tea and get back to work before Alice comes looking  
for him with a tire-iron in hand.  Seems like a useful bit, eh?

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 28 Sep 2005 08:34:58 +0300

how about collecting calls information at the proxy and making it
available to the user via web pages and a click-to-dial capability.
this is what we currently do and users seem quite happy with it.

-- juha

---

From: "Banibrata Dutta" <[email-masked]>
Date: Wed, 28 Sep 2005 11:40:28 +0530

Without having read the entire draft (I quickly skimmed thru it), I have a
feeling that if we are planning to extend the scope from missed-calls (or
even with the limited scope) to calls placed or successfully received, we
should put in place some mandatory privacy mechanisms. Such
records/information is previleged and can be sensitive.

my $0.02,
- banibrata dutta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Wednesday, September 28, 2005 3:15 AM
To: Jeroen van Bemmel
Cc: Francois Audet; [email-masked]
Subject: Re: [Sipping] Internet draft on missed calls / msgs notification

Jeroen van Bemmel wrote:
> requirements, and add that to the draft under section 3 (which now has 
> 3 lines describing the problem). So far we have:
> - the list of calls for a given identity SHOULD be complete, meaning 
> it SHOULD include information on calls placed while no endpoints were 
> (e.g. forked calls, 1 endpoint reports 'busy' and the other accepts, 
> how is the call logged?)

I agree.

And calls that were placed, rather than received, are also of interest. 
Again there is the value of seeing a consolidated list of all for the AOR,
rather than just those placed by a particular UA.

	Paul

> I think the key point is Dave's point about the ability to see missed 
> calls on a variety of devices that may not have received the INVITEs 
> in the first place.
> 
> example, or a mobile device, it will not be able to see the "missed 
> calls" that landed elsewhere (on the desk phone at work, or on a home 
> phone or whatever).
> 
> The "cost of server" argument is interesting, but it really depend on 
> the enviroment you are in. In some environments, like an Enterprise 
> 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
> 
> 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: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 28 Sep 2005 09:58:03 +0200

Juha,

A "call events" package would not preclude that, you could have both. I 
think it would be nice if also endpoints without web browsers could present 
such information to their user, perhaps in a less fancy way

A question that pops to mind: would an endpoint have to report directly 
placed calls (which did not go via its AoR proxy) to the AoR proxy? (to 
enable viewing that information on other endpoints)

JvB

----- Original Message ----- 
From: "Juha Heinanen" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>
Cc: "Jeroen van Bemmel" <[email-masked]>; "Francois Audet" 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, September 28, 2005 7:34 AM
Subject: Re: [Sipping] Internet draft on missed calls / msgs notification

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Sep 2005 09:31:10 -0400

comment at end.

	Paul

Dean Willis wrote:
> * A call was sent to your AOR, but since you have diverted all calls  to 
> voice-mail, it was sent there.
> 
> * A call was sent to you AOR, and forked to your contacts, one of  which 
> replied with a "busy everywhere" response causing us to reject  the 
> call. Perhaps you should check into it.
> 
> That is to say, perhaps such a package could reflect both 1)  processing 
> decisions made by a serving proxy for an AOR in response  to a request, 
> 2) history information contained in that request,  especially if such 
> information is used in the processing of the  request, and 3) history 
> information gleaned from processing of the  request in other nodes on 
> alternate paths "downstream" from the proxy.
> 
> switches send when they've diverted a call away from a subscriber  line 
> as a result of call forwarding. Or it could tell employee Bob in  the 
> call center that fellow employee Alice just took a call, and that  she's 
> taken the last three calls for the call center, and perhaps he  should 
> finish his tea and get back to work before Alice comes looking  for him 
> with a tire-iron in hand.  Seems like a useful bit, eh?

Dean, I am in at least partial agreement with where you are going. But 
note that it isn't this package that *does* all those things. It is 
applications in the UA that use the package to help them do these things.

	Paul

---

From: "Dale R. Worley" <[email-masked]>
Date: Fri, 30 Sep 2005 11:28:58 -0400

I think the "server vs. peer-to-peer" distinction is a bit too simple.
In reality, a SIP call could go through multiple levels of routing and
translation, each of which has its own logical view of "call history".

Consider a "hot line" AOR that routes to a changing group of people who
answer the hot line.  One of those people has his own AOR, which has a
several contacts.  One of those contacts is a mobile phone, which is
sometimes off-network.

The mobile can keep a call history, but of course it can't log calls
missed because it was off-network, though it can log calls that were
missed because it was busy.

The individual's AOR has to be handled by a server (or a coordinated
distributed set of agents which perform logically like a server), and
that server (those servers) can keep a call history for calls that
routed through the individual's AOR.

The hot line AOR's server similarly keeps a call history.  But of course
calls placed directly to the individual's AOR don't feature in the hot
line AOR call history.

This also points out that the record for a call ideally contains
information about the responses of all end-points of the call -- it's
possible that one UA was busy, and a second UA was unreachable (off-
network).  To keep sensible state, both of those data need to be
recorded.

We may also want to consider logging information from the "call
redirection" information that people are talking about.

Dale

---

From: [email-masked]
Date: Fri, 30 Sep 2005 11:20:44 -0500

>In reality, a SIP call could go through multiple levels of routing 
>and translation, each of which has its own logical view of "call history".

This is true and comes with a price tag however and the point of view
differs if you are the payer or the payee :-)

A user group such as "Our Class Reunion" can set up an ad hoc P2P network at
no cost if their SIP UA can support P2P and its features, such as voice
mail.

A "hot line" or emergency call center has obviously very different
requirements that may be better implemented in complex SIP server clouds;
though it could be argued that a self organizing P2P SIP server cloud has
lower cost for operations and is more resilient as well.

The proposed P2P SIP BOF at the 64 IETF may bring some light on this.

Call history and the logs can be very critical for legal reasons or help
with CALEA type of requirements but may be of less importance for small
communities of interest.

Thanks, Henry

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: Friday, September 30, 2005 10:29 AM
To: Sipping
Subject: RE: [Sipping] Internet draft on missed calls / msgs notification

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Sep 2005 13:51:08 -0400

> with CALEA type of requirements but may be of less importance for small

I think they are of potential value for many reasons, even among small 
communities. But I think this should clearly be an optional capability. 
You can only subscribe to it if it is available.

In communities where presence is universally used, and universally 
available, missed calls probably just won't happen, because people won't 
call if you aren't present. In that case a missed call list is probably 
of no interest.

But in any community where there are users that are strangers to one 
another, and that don't permit all to see their presence, there will be 
missed calls. In that kind of context a missed calls list is useful.

And I believe a missed call list based in a server rather than just in 
the UAs, is more important when the UAs are mobile or soft than it is 
when they are "always on" as is the case in the traditional wired 
telephone network.

	Paul