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

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Tue, 27 Sep 2005 16:03:02 -0400

I agree.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Francois Audet
Sent: Tuesday, September 27, 2005 3:02 PM
To: [email-masked]
Subject: RE: [Sipping] Internet draft on missed calls / msgs
notification

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

_______________________________________________
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: "Summers, Kevin" <[email-masked]>
Date: Tue, 27 Sep 2005 17:12:08 -0500

I am in complete agreement that this sort of information would be very useful. 

Couldn't the dialog package (or some variation) be used to notify this sort of information?         

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Paul Kyzivat
Sent: Tuesday, September 27, 2005 4:45 PM
To: Jeroen van Bemmel
Cc: Francois Audet; [email-masked]
Subject: Re: [Sipping] Internet draft on missed calls / msgs
notification

Jeroen van Bemmel wrote:
> 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?)

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]>
> Sent: Tuesday, September 27, 2005 9:02 PM
> Subject: RE: [Sipping] Internet draft on missed calls / msgs notification
> 
> 
>

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Wed, 28 Sep 2005 09:29:37 -0400

Let me try to add couple of scenarios.

>From server modeling point of view, an application server (e.g., proxy
with B2BUA, AS) will be in charge providing services, and it is supposed
to know that the call has been missed (others like user policies may
also play a role). It is a clear cut specific approach where a simple
solution can be found based on this assumption. However, it is one sided
centralized server model.

For P2P point of view, if a call is not accepted by a given peer, it may
be forwarded to the next peer and so on. Depending on the peering
modeling schemes (it is an assumption because we have not developed the
P2P-SIP protocol yet), it appears that it will create an history along
the peering path what has been the faith of the call. However, we have
to develop the p2p protocol first before solving this using peering
schemes.

The other end of the spectrum is to dig into analysis what Dean has
already proposed based on many if and what scenarios using the usual SIP
schemes. In this way, we can also see whether we can see the light at
the end of the tunnel.

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Arjun Roychowdhury
Sent: Wednesday, September 28, 2005 7:10 AM
To: Avasarala Ranjit-A20990
Cc: [email-masked]
Subject: Re: [Sipping] Internet draft on missed calls / msgs
notification

The intent of the draft is well placed and useful. However, I wonder
if this draft makes an assumption that the network service is only
provided by one entity.

The concept of service execution in SIP was that multiple nodes could
be participatory. In the case of a 'missed call' a proxy may be just a
default forwarding device to an AS that really decides if the call is
missed. Similarly, depending on other factors, the AS itself may be
'handing off' a call to another node, say a B2B. The AS thinks that
the call is actually connected whereas the B2B knows it is not.

The question therefore arises as to who really knows that the call is
really missed and who reports. More importantly, if the notion of the
service result is shared between multiple nodes, no one node could
really report effectively.

Therefore, is the concept of 'call history' more applicable here as a
primitive that needs be specified and missed call a construct on top
of it ? I

On 9/23/05, Avasarala Ranjit-A20990 <[email-masked]> wrote:
>
>
> Hi
>     I want to propose an internet draft on notification for missed
calls/
> messages thru XML event package. Plz go thru it and give your
comments.
>
> Thanks
> <<draft-ranjit-missed-calls-msgs-00.txt>>
>
> Regards
> Ranjit