Dave Platt wrote:
>> I may be over simplifying but I would have a serial number object that
>> gets incremented anytime it is called and will be set to 0 at start-up.
>> I would then use it to generate a UUID like this:
>> MAC.serialid.64bit timedate
>>
>
> I suggest reviewing RFC 4122, whic
Tilghman Lesher wrote:
> On Friday 09 January 2009 13:52:56 Anthony Francis wrote:
>
>> Tilghman Lesher wrote:
>>
>>> We are entirely interested in DETERMINISTIC methods of uniqueness, not
>>> random and hope-for-the-best. Given a truly random generator, it is
>>> possible for the same num
> I may be over simplifying but I would have a serial number object that
> gets incremented anytime it is called and will be set to 0 at start-up.
> I would then use it to generate a UUID like this:
> MAC.serialid.64bit timedate
I suggest reviewing RFC 4122, which discusses UUID formats in some
On Friday 09 January 2009 13:52:56 Anthony Francis wrote:
> Tilghman Lesher wrote:
> > We are entirely interested in DETERMINISTIC methods of uniqueness, not
> > random and hope-for-the-best. Given a truly random generator, it is
> > possible for the same number to come up 100 times in sequence.
Tilghman Lesher wrote:
> On Friday 09 January 2009 01:14:37 Grey Man wrote:
>
>> On Fri, Jan 9, 2009 at 6:37 AM, Tilghman Lesher wrote:
>>
>>> I think Steve is as interested as anybody else in achieving a solution,
>>> but you're hand-waving when it comes to the establishment of a UUID.
Steve Murphy wrote:
> Sorry, I apologize for the 'uniqueID' field; I didn't invent it, or name
> it, and there is little definition for it. I think it's accidental that
> a transfer could yield two CDRs with the same uniqueID. I'm all for just
> simply dropping it. Maybe I will.
I would ask that
On Friday 09 January 2009 01:14:37 Grey Man wrote:
> On Fri, Jan 9, 2009 at 6:37 AM, Tilghman Lesher wrote:
> > I think Steve is as interested as anybody else in achieving a solution,
> > but you're hand-waving when it comes to the establishment of a UUID.
> > There is no such construct that we ca
On Fri, Jan 9, 2009 at 3:08 PM, Steve Murphy wrote:
>
> By appending another string, you can guarantee it is unique across
> systems.
> So, if you use a system name, or Asterisk server name, that you yourself
> guarantee to be unique among all the asterisk servers that would
> contribute
> CDRs to
On Fri, 2009-01-09 at 04:24 +, Grey Man wrote:
> On Fri, Jan 9, 2009 at 3:48 AM, Steve Murphy wrote:
> >
> > But, since it is timestamp based, and unique in that the final part was
> > incremented per request in the same sec, it made a great item to sort
> > on, and allowed me to implement lin
On Fri, Jan 9, 2009 at 6:37 AM, Tilghman Lesher
wrote:
>
> I think Steve is as interested as anybody else in achieving a solution, but
> you're hand-waving when it comes to the establishment of a UUID. There
> is no such construct that we can use, but there are very deterministic methods
> (which
On Thursday 08 January 2009 22:24:45 Grey Man wrote:
> On Fri, Jan 9, 2009 at 3:48 AM, Steve Murphy wrote:
> > My advise is not to. I have no prob with uuids, except that they are
> > 36 bytes, and overkill for uniqueness. linkedID + system name would be
> > totally sufficient; One glance at the l
On Fri, 2009-01-09 at 01:53 +, Grey Man wrote:
> I would be interested in additional information in the CDRs as I'm
> sure others would. My worry is it's not a critical peice of CDR
> information and because it sounds like information being generated at
> the dialplan level it could end up bei
On Fri, Jan 9, 2009 at 3:48 AM, Steve Murphy wrote:
>
> But, since it is timestamp based, and unique in that the final part was
> incremented per request in the same sec, it made a great item to sort
> on, and allowed me to implement linkedID's.
Again that's mixing fields that shouldn't be. The c
On Fri, 2009-01-09 at 01:40 +, Grey Man wrote:
> On Thu, Jan 8, 2009 at 7:22 PM, Asterisk Development Team
> wrote:
> > Actually I could see appending a 'servername' to the UUID as useful in a
> > clustered environment. Every time I don't think I need to do that, I end
> > up having to do it.
On Thu, Jan 8, 2009 at 6:22 PM, Steve Murphy wrote:
>
> In general, stuff like FXO's activating, would signal an incoming call,
> but gee, I could wire up some odd circuit to make it a local
> extension...
> Some external rule to the pbx determines which devices and peers you'll
> want to pay
On Thu, Jan 8, 2009 at 7:22 PM, Asterisk Development Team
wrote:
> Actually I could see appending a 'servername' to the UUID as useful in a
> clustered environment. Every time I don't think I need to do that, I end
> up having to do it. And since this would be a configurable appendage, it
> should
On Thu, Jan 8, 2009 at 7:34 PM, Leif Madsen
wrote:
> My apologies. I had installed a tool for posting Asterisk releases, and
> forgot to turn off all the automatic stuff. This was a reply that
> reflects my personal opinions on the matter, not all of the Asterisk
> Development Team.
Pity, I thoug
Grey Man wrote:
> A single CDR should not be able to cover several Dial attempts or even
> multiple destinations within the same Dial attempts. If you think of
> Dial as just another application and of CDRs being designed to reflect
> the lifetime of a channel then things are simplified. If a Dial
My apologies. I had installed a tool for posting Asterisk releases, and
forgot to turn off all the automatic stuff. This was a reply that
reflects my personal opinions on the matter, not all of the Asterisk
Development Team.
My bad :(
Leif Madsen.
> Asterisk Development Team wrote:
>
On Thu, 2009-01-08 at 16:20 +, Grey Man wrote:
> On Wed, Jan 7, 2009 at 6:01 PM, Steve Murphy wrote:
> > On Wed, 2009-01-07 at 02:56 +, Grey Man wrote:
> >> On Tue, Jan 6, 2009 at 3:53 PM, Steve Murphy wrote:
> >>
> >> That sounds a bit dangerous to me. If you go down the path of setting
On Wed, Jan 7, 2009 at 6:01 PM, Steve Murphy wrote:
> On Wed, 2009-01-07 at 02:56 +, Grey Man wrote:
>> On Tue, Jan 6, 2009 at 3:53 PM, Steve Murphy wrote:
>>
>> That sounds a bit dangerous to me. If you go down the path of setting
>> the answer time based on dial plan applications or events
The continuing discussion on a future "Simple CDR" mode of generation...
from which I will extract the info and add a section to the
overall CDR spec I'm developing...
For newcomers, "Simple CDR" mode would not break the conversations
into legs at all. Each CDR would simply record the total time
Steve Murphy wrote:
> So, what I'm thinking, is to spec out two CDR generation modes,
> one detailed one according to the spec I'm working on, and the
> other mode will follow these lines...
Hmmm... I'm liking this idea so far.
> On Tue, 2009-01-06 at 10:37 +, Grey Man wrote:
>>> so, if A c
Greyman--
I'm taking this discussion to the list.
Folks,
what we are talking about here, is me trying to get a grasp around
Greyman's (Aaron's) request for a bare-bones CDR generation
that describes just total connect time for channels, stripping
out all the details. Who cares about xfer, park
Suggestions on how to use Asterisk to collect CDRs from a OpenSER-based
proxy / call routing setup? I need to get simple CDRs; not for detailed
settlement/rating, but just for reconciliation with an ultimate TDM
carrier just to make sure we only get billed for what we're actually
using.
I'd u
Asterisk is poor with codec negotiation . It does not check if it can avoid
transcoding by forcing codec available to both sides .. instead it will
read it's config file and will select first allowed codec that is also
available on other device on each leg of call and happily transcode between
t
26 matches
Mail list logo
