Subject: RE: [Sipping] Missed calls event package

From: "Gordon Ledgard" <[email-masked]>
Date: Tue, 28 Jun 2005 11:12:34 -0400

I agree with David on a few points: First, a general call logging method
should not be dependant on an Event package.  While its not inappropriate
for agents and/or the network to share selected log information using
events, its not really an appropriate for generic logging. Its far too
cumbersome an approach for a function that is fundamentally simple.  Second,
rather that focusing on specific mechanisms for storing and retrieving
logs, which is highly dependant on implementation architectures and third
party subsystems outside the scope and control of SIP, the focus should be
simply on a schema to represent the data, XML being an excellent choice. 
Perhaps a definition of an API to retrieve that data, short of calling out a
particular storage implementation, might also be appropriate.

Finally, directory services are also much too application/implementation
specific to warrant a standardization, I think. In order to satisfy
everybody the recordkeeping for the directory entries would need to be
enormous, and in the end, would satisfy no one.

Regards,
Gordon Ledgard
IPeria, Inc.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of David R Oran
> Sent: Tuesday, June 28, 2005 10:41 AM
> To: [email-masked]
> Cc: Paul Kyzivat; [email-masked]; Dean Willis
> Subject: Re: [Sipping] Missed calls event package
> 
> 
> On Jun 28, 2005, at 10:29 AM, [email-masked] wrote:
> 
> >
> > 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.
> >
> 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.
> 
> 
> > 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
> >
> >
> >
> >
> >
> >
> > On Jun 28, 2005, at 8:40 AM, Paul Kyzivat wrote:
> >
> > >
> > >
> > > Avasarala Ranjit-A20990 wrote:
> > >
> > >> 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.
> > >>
> > >
> > > 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.
> >
> > >     Paul
> > >
> > >
> > >>  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
> > >>
> > >
> > > _______________________________________________
> > > 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

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 28 Jun 2005 16:50:58 +0100

> From: Jeroen van Bemmel [mailto:[email-masked]] 
> Sent: 28 June 2005 07:21
> To: Paul Kyzivat
> >> 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
> 
> 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
[JRE] Yes, I am interested, both in a schema and in a SIP event package to
notify a UA that more records are available. Whether these records are
supplied using the event package or whether they are retrieved separately is
an open question.

John