[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Avasarala Ranjit-A20990 wrote: 
Hi Paul,

My comments inline... {Ranjit] 

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

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

Thanks

Regards
Ranjit




-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com] Sent: Wednesday, September 28, 2005 7:12 PM
To: Arjun Roychowdhury
Cc: Avasarala Ranjit-A20990; sipping at ietf.org
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 <ranjit at motorola.com> 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 sip-implementors at cs.columbia.edu for questions on current sip Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP