[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
|