The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Caller ID Lookup / Display / Log


  • Subject: Re: Caller ID Lookup / Display / Log
  • From: Stuart Booth
  • Date: Sun, 07 Mar 2004 17:25:00 +0000

Forgot about your question here, Kevin, sorry!

On Mon, 23 Feb 2004 04:18:40 -0000, "Kevin Hawkins"
<<a
href="/group/xAP_developer/post?postID=N5Cxz9EvgSA0Yl1J1Q9HkSuaUHW7ITz8N5FIJT348X2PVFCAhDHR-n7jjGZgj4gmyH4dqjs0f6XEALFKxTk">lists@u...</a>>
wrote:

>In the CID.Meteor Incoming.CallWithNoCID block you have a mandatory
"Type"
>parameter - but if the incoming callerID information is not present on
a
>call then you don't know what type of call it is ie
>VoiceRingbackMessageWaiting. This particular
"IncomingCallWithNoCID"
>block would never have this present so I don't see how it can be a
mandatory
>parameter ??

That doesn't make any sense really does it. Shall we drop it entirely?
That will make the block very empty.

Maybe the Date/Time should be Mandatory though. It is where CID
information is available for instance, and would be known from the
time the unidentifiable call event is raised.

However, Date/Time in the CID info present case comes from the CID
info block, and also from the information on the computer as I recall
(it has been yonks since I did absolutely anything with any of this).

I figured we could/should re-use the 'standard' date/time formatting
style rather than create yet another variant, even though the CID
information, at least on UK lines, only includes time I think? Is that
right? It's something like that anyway. I fleshed out the basic
information from the CID info block with information from the
monitoring system if possible.

Okay, I checked, the CID info block only contains MM/DD and HH:MM, so
the seconds would always be zero (unless the CID xAP can provide this
information) and the year, well, that's an interesting one I suppose.

What say the device doesn't have a clock built into it, it cannot
therefore infer year, so the date/time field would then be malformed
unless 0000 is assumed to be the current year.

It seems like a good idea to stick to one date/time format across all
xAPs where possible. But leaving that parameter as optional fits
better with UK CID information at least.

>I do intend to add a couple of extra parameters to some of the
CID.Meteor
>blocks - including perhaps the BT datetime value

Ohhhhh, you really do want that value in there? It doesn't need both
though does it? The 'standard' format covers all cases where different
implementations of CID provide more complete information, the BT
example (assuming 0000 for year means the current year), and being
optional covers the case where it isn't available at all.

The BT format may not apply to other systems.

> and more importantly a
>parameter for 'digits dialled so far' certainly within the
>Outgoing.DigitPressed and perhaps the Incoming.DigitPressed blocks.

I'll update the docs with these changes if you like.

S
--
Stuart Booth <<a
href="/group/xAP_developer/post?postID=a4OhEUs89xvj4yms8XoiY_v6jb1WfBI7wylzb0mytO07r39o_pEw_UznphZ1XBgvESbJxSN9F9fwQ-YGSg3e">stuart@x...</a>>
xAPFramework.net - a xAP software development framework for .net

<a href="http://www.xapautomation.org/";>http://www.xapautomation.org/</a>
<a href="http://www.xapframework.net/";>http://www.xapframework.net/</a>





xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.