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

From: "Eric Burger" <[email-masked]>
Date: Fri, 28 Oct 2005 16:24:26 -0400

I would also strongly suggest looking at the MSGTRK work from the e-mail
world.  A lot of the same issues (and solution space exploration) have
been examined already.

See RFC 3888 and RFC 3885-3887.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Wednesday, September 28, 2005 12:51 PM
To: Avasarala Ranjit-A20990
Cc: [email-masked]
Subject: 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:[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
> 

_______________________________________________
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