Subject: RE: [Sipping] Missed calls event package

From: Avasarala Ranjit-A20990 <[email-masked]>
Date: Tue, 28 Jun 2005 17:12:19 +0530

Hi
     The call history is anyway maintained in the UA, like recent calls. So
I am not sure how useful the event package will be. Also the event package
will be stored on server. 
 If we have this event package, that package could have a mechanism where
the user will subscribe for call history and server will send the call
history at periodic intervals. or everytime there is a change in the call
history data. 

 Is this what we are speaking about?

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jeroen van Bemmel
Sent: Tuesday, June 28, 2005 11:51 AM
To: Paul Kyzivat
Cc: [email-masked]; Dean Willis
Subject: Re: [Sipping] Missed calls event package

>> You could of course simply scan for all 'From' headers you can find, 
>> but
>
> Scan *what*?
>

The body of the NOTIFY you get from MWI. But I think you agree with me here 
that it is not that simple

> This could be an area for new work, starting with trying to define the
> requirements. You would have to see if there is sufficient interest to 
> pursue it at this time.
>

Right. So this is a call for interest: I am hereby asking people to respond 
to the mailinglist with comments and/or indication of interest in this topic

Thanks and regards,

Jeroen

_______________________________________________
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: Tue, 28 Jun 2005 08:40:14 -0400

> history at periodic intervals. or everytime there is a change in the call

A UA can only maintain the history that it is aware of. If there can be 
multiple UAs servicing the same AOR, or if a proxy intervenes on some 
calls to the AOR, then a UA does not have a complete history of calls - 
missed, received, or placed.

Do you want your livingroom phone to think there was a missed call, when 
in fact it was answered in the bedroom?

	Paul

---

From: David R Oran <[email-masked]>
Date: Tue, 28 Jun 2005 09:51:27 -0400

On Jun 28, 2005, at 8:40 AM, Paul Kyzivat wrote:

>> will be stored on server.  If we have this event package, that  
>> package could have a mechanism where
> A UA can only maintain the history that it is aware of. If there  
> can be multiple UAs servicing the same AOR, or if a proxy  
> intervenes on some calls to the AOR, then a UA does not have a  
> complete history of calls - missed, received, or placed.
>
> Do you want your livingroom phone to think there was a missed call,  
> when in fact it was answered in the bedroom?
>
This was in fact one of the motivating cases for the reason header on  
CANCEL - the UA receiving the CANCEL could tell the difference  
between an abandoned call and one that was picked up at a different UA.

That of course does not allow a UA to learn about calls to the AOR  
that were missed while the UA was offline, or calls whose caller  
prefs caused the UA to be bypassed and not contacted, or calls that  
got screened out, etc.

I think a standardized way to obtain a call log for an AoR with the  
appropriate dispositions for each call would be a very nice thing.  
Not clear the right way to do it is an event package though. In any  
event, an common "call log" XML schema seems to be a prerequisite to  
making any particular fetch or notification machinery work in an  
interoperable fashion.

Could we start there?

Dave.

>>>> You could of course simply scan for all 'From' headers you can  
>>>> find, but
>>>>
>>>
>>> Scan *what*?
>>>
>>>
>> The body of the NOTIFY you get from MWI. But I think you agree  
>> with me here that it is not that simple
>>
>>> requirements. You would have to see if there is sufficient  
>>> interest to pursue it at this time.
>>>
>>>
>> Right. So this is a call for interest: I am hereby asking people  
>> to respond to the mailinglist with comments and/or indication of  
>> interest in this topic
>> Thanks and regards,
>> Jeroen

---

From: [email-masked]
Date: Tue, 28 Jun 2005 10:29:52 -0400

Hi,

I totally agree with what David said.
We should have a generic mechanism for call logs which will suffice for 
this requirement too.
It is more like data retreival from the server.

We can have a similar mechanism for providing directory services using 
SIP. I havent seen any SIP thread for directory services.

Regards,
Udit

David R Oran <[email-masked]> 
Sent by: [email-masked]
06/28/2005 09:51 AM

To
Paul Kyzivat <[email-masked]>
cc
[email-masked], Dean Willis <[email-masked]>
Subject
Re: [Sipping] Missed calls event package

Could we start there?

Dave.

---

From: David R Oran <[email-masked]>
Date: Tue, 28 Jun 2005 10:41:19 -0400

On Jun 28, 2005, at 10:29 AM, [email-masked] wrote:

> We should have a generic mechanism for call logs which will suffice  
> for this requirement too.
I agree, which is why I think the first step is a schema and we can  
then provide one or more access mechanisms. If we choose http: as one  
of them, it might also be nice to have a uri convention for accessing  
the log, e.g. http://[email-masked]/call-log/?start=1-june-2005:08:00.

> We can have a similar mechanism for providing directory services  
> using SIP. I havent seen any SIP thread for directory services.
>
LDAP? ENUM? Let's not turn SIP into some über-protocol that has to do  
everything. So while I agree about call logs, I disagree about  
directories, especially whn one considers that buddy lists are going  
to have complex interactions with directories that make this less- 
than straightforward to map into SIP or Presence.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Jun 2005 10:51:15 -0400

> event, an common "call log" XML schema seems to be a prerequisite  
> to making any particular fetch or notification machinery work in an  
> interoperable fashion.

If we take the web as an example, there are semi-standardized web log  
formats that are then processed by a plethora of tools to yield  
statistics as well as to debug server behavior. Having such formats  
for SIP would be very useful as well. I don't see events as  
particularly applicable; in most cases, one would want to look at a  
filtered version of a larger number of records, e.g., to sort by  
caller, callee, or to compute statistics. (There are exceptions; for  
example, it would be useful to be able to easily show on an end  
system all calls missed since the last call was placed.)

Unlike HTTP, there are however at least two types of such logs:  
request logs and call logs. One can derive the latter from the  
former. Also, call logs wouldn't necessarily capture MESSAGE and  
NOTIFY and other non-INVITE transactions.

Given the timelines involved in SIPPING work and its non-protocol  
nature, maybe the SIP Forum would be an appropriate venue for such a  
call or request log agreement.

Henning

---

From: [email-masked]
Date: Tue, 28 Jun 2005 11:38:52 -0400

Henning Schulzrinne <[email-masked]> 
Sent by: [email-masked]
06/28/2005 10:51 AM

To
David R Oran <[email-masked]>
cc
Paul Kyzivat <[email-masked]>, [email-masked], Dean Willis 
<[email-masked]>
Subject
Re: [Sipping] Missed calls event package

>or SIP would be very useful as well. I don't see events as

I agree with that. Mostly, users want to have look at filtered records.
This will require concensus on whether we only want to give the 
information to the agent, or provide mechanism also to filter that data. 
Because agents can also filter that data itself.

We should also consider the fact that if agents are using this approach, 
then they are not going to have call logs implemented on the UA itself, 
because then it may have synchronization issues.

>NOTIFY and other non-INVITE transactions.

Does it really help UA to know SIP request logs. I feel call logs is of 
main interest to the user.
However, request logs are helpful when you are interested in performance 
data and other statistics.

Henning

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 28 Jun 2005 23:48:44 +0200

----- Original Message ----- 
  From: [email-masked] 
  To: Henning Schulzrinne 
  Cc: [email-masked] ; Paul Kyzivat ; David R Oran ; Dean Willis 
  Sent: Tuesday, June 28, 2005 5:38 PM
  Subject: Re: [Sipping] Missed calls event package

        Henning Schulzrinne <[email-masked]> 
        Sent by: [email-masked] 
        06/28/2005 10:51 AM 
       To David R Oran <[email-masked]>  
              cc Paul Kyzivat <[email-masked]>, [email-masked], Dean Willis <[email-masked]>  
              Subject Re: [Sipping] Missed calls event package 

  >system all calls missed since the last call was placed.)

Or perhaps all calls missed since the last time you were REGISTERed through some device. This is a scenario I've been thinking of, perhaps the REGISTER reply could contain information for the UA about missed calls (e.g. the URL to where the missed call log may be found, and/or an indication of the number of calls missed)

  I agree with that. Mostly, users want to have look at filtered records. 
  This will require concensus on whether we only want to give the information to the agent, or provide mechanism also to filter that data. Because agents can also filter that data itself. 

  We should also consider the fact that if agents are using this approach, then they are not going to have call logs implemented on the UA itself, because then it may have synchronization issues. 

I would say both features will occur and have to interoperate somehow, especially since there are already many devices out there that support a local call log. Instead of banning that, we should consider the requirements for making sure that the device can properly synchronize its state. I.e. how to correlate logs ( call-id ? but then what about forked sessions? ) and things like time synchronization or lack thereof

  >NOTIFY and other non-INVITE transactions.

  Does it really help UA to know SIP request logs. I feel call logs is of main interest to the user. 
  However, request logs are helpful when you are interested in performance data and other statistics. 

  Henning

------------------------------------------------------------------------------