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

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Wed, 28 Sep 2005 23:19:30 +0800

Hi Paul,

My comments inline... {Ranjit] 

Also I want to know what modifications I need to make to take this
forward.

Thanks

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, September 28, 2005 7:12 PM
To: Arjun Roychowdhury
Cc: Avasarala Ranjit-A20990; [email-masked]
Subject: Re: [Sipping] Internet draft on missed calls / msgs
notification

Arjun,

Arjun Roychowdhury wrote:
> 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.

I think it makes the assumption that the subscription terminates on one
entity that can provide the requested information. How that entity gets
the information is another story. There is a little bit of text that
hints at a mechanism. I couldn't get much out of it - it might be overly
restrictive. In any case, I think the mechanism for gathering the
information can be independent of the mechanism for retrieving it.
[Ranjit] True. Subscription terminate sat the server which will service
the subscription. Usually proxy or AS. 

> 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.
   [Ranjit] The subscriber would be interested in retrieving the calls /
messages missed by him when his mobile / device was out of network.
Although the details of the mechanism of knowing when the mobile was IN
and Out of network is out of ntwork. There could be a mapping between
GPRS cell updates and SIP AS to provide information to AS to start and
stop the service.
> 
> 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
[Ranjit] Call history would include dialed and answered calls, which
will anyway be stored  Right this package could be enhanced to
accommodate them, but then the purpose would change to "call-history"
package. Is that what the idea is?

I agree that more work is needed, on a sort of framework, to determine
how this information can be determined.

If we just view this as a "call log", that contains what information is
known about calls, then we can perhaps dodge fully defining what
constitutes a "missed" call. (IMO there is no single definition that
everyone would agree on.) The log would just capture what information is
available to it, and watchers can develop their own criteria for what
constitutes "missed", if that is what they want to know.

	Paul

> 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
>>
>>
>>
>>_______________________________________________
>>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
>>
>>
>>
> 
> 
> 
> --
> Arjun Roychowdhury
> 
> _______________________________________________
> 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: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Sep 2005 12:51:18 -0400

> Also I want to know what modifications I need to make to take this

I think you now have some good "buzz" going, and that the conversation 
is being helpful in identifying additional ideas. So I think you should 
for the moment let the conversation continue for a bit.

When it dies down, it would be good to summarize and synthesize it. I 
think the direction is toward something more general than what you had 
in mind.

I am thinking that perhaps there will be multiple components in the 
solution, and that a framework document might be in order to identify 
the pieces and their relationships. In particular you have:
- watchers that are interested in the information,
   potentially for a variety of reasons that could be described
- potentially filters on what the watchers want to see
- a notifier that delivers the info to the watchers
- one or more sources of the information
- a compositor that assembles all that information

It is quite a bit like the presence infrastructure, though the details 
are different, and hopefully there won't need to be as many sources of 
information.

	Paul