Delayed Contributions and Input TDs

Sakae OKUBO okubo at
Fri Sep 4 07:16:11 EDT 1998


Although billing for IP based calls is very likely to be very different
from that used in the PSTN world, (and I would be prepared to bet that
it was distance independent!!!), I think it is far too early to enshrine
such a concept into the work we are doing.  For example, an operator,
possibly a start up, may want to connect a big fat intra-net style IP
pipe out the back of there new local POTS point of presence and use that
to inter-connect with the rest of their network.  They would want to
have the option of doing distance based charging so that they can shadow
their competitors on pricing policy.  I don't think we should dive into
billing etc., but I still think we need to allow for geographically
based routing.

On the following the sun policy, I see this as much the same as 'basic'
user mobility.  I would expect this to be based around something like
home and foreign gatekeeper concepts that have been posted on this list.


Pete Cordell
BT Labs
E-Mail: pete.cordell at
Tel: +44 1473 646436
Fax: +44 1473 645499

>From:  Douglas Clowes[SMTP:dclowes at OZEMAIL.COM.AU]
>Sent:  03 September 1998 02:57
>Subject:       Re: H.323 Addresses
>Hi All,
>It's a shame I wasn't on the call, I might find out what's going on :-(
>Thanks to those who are exposing it on the list. :-)
>In my mind, address resolution (or number translation) is a multistage
>In the context of the caller, a destination address may be an
>form like an abbreviated dialing number (*21), a service prefixed
>(01161294332374), or a nickname ("doug"), that has to be translated
>into an
>"external" form. The result of this stage is an external address.
>Once in the external form that identifies the callee, the number is
>to resolution in the context of the callee. I think that 800 numbers
>like this. Since geographical information is probably not known about
>source or the destination, much less path metrics between them,
>that into the resolution may be a problem. The result of this stage is
>effective address.
>If the response is a prioritised sequence of endpoints, then the source
>select from the endpoints within each priority based on
>For example 1-800-555-1212 => (1-415-555-1212, 1-212-555-1212) and I
>select my area code if I know it.
>The third step involves endpoint location, sometimes called gateway
>location. This involves taking the effective address and locating a
>physical (transport) address that can handle it. This could also be a
>prioritised sequence of endpoints (gateways), for each effective
>The source can then select from the endpoints within each priority
>based on
>characteristics. I might look in my IP routing tables, ping them or use
>I don't think that "geographical" proximity is the *real* determining
>factor here. It doesn't matter if the source is sitting on top of the
>destination if the link is a 300 baud serial line.
>I think that the problem being canvased here is one that comes from the
>PSTN domain where the 800 charges are distance dependent. I don't think
>that it translates directly to the packet network domain, where charges
>often distance independent.
>What's more likely to be interesting, is the moving call centre where
>effective address follows the sun from London to San Francisco to
>Sydney to
>maximise daytime staff utilisation. Here your 1-800 number will
>to 44-171, 1-415, and 61-2 depending on the time of day.
>At 18:01 02/09/98 +0100, Chris wrote:
>>Good point, Pete!  It's a shame you weren't on the call (there was a
>>certain amount of guesswork as to how 800 numbers work)!
>>There are two ways of handling this that I can see immediately.  Although
>>philosophically different, in practice they will normally amount to the
>>same thing:
>>1. The "owner" of a domain needs to be told where a query originates,
>>given that the calling location may affect the answer it gives or:
>>2. A border element handling queries for 800-type numbers needs to know
>>what to do with it depending on the origin of the query.
>>Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
>>Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks.
>>Phone:+44 1753 661359  email: cpurvis at
>>Dear All,
>>It may not be possible to handle 800 numbers in the same way as other
>>numbers as the destination may be based on the geographical location of
>>the caller.  For example, ISPs may be accessible by something like an
>>800 number which may be fixed for a whole country, but the POP you end
>>up connected to may vary depending on where you called from.
>>I'm not sure what the implications of this are, but it is something to
>>think about!!!
>>Pete Cordell
>>BT Labs
>>E-Mail: pete.cordell at
>>Tel: +44 1473 646436
>>Fax: +44 1473 645499
>>>From:  Chris Purvis WVdevmt-WS[SMTP:cpurvis at MADGE.COM]
>>>Sent:  02 September 1998 13:09
>>>Subject:       Re: H.323 Addresses
>>>>We are discussing about H.323 addresing schemes in our bi-weekly H.323
>>>>inter-GK conf calls.
>>>>The H.323 addresses that are being considered are 1. E.164, 2. E-mail,
>>>>URL, and 4. TCP/UDP/RTP port addresses (and 5. aliases as well I
>>>>Although a hierarchical notion of addressing scehmes have been
>>>discussed, we
>>>>have also recognized that some other variations of addressing schemes
>>>>For example, people change their physical locations, but they might
>>>>keep the same E.164 addresses. So, a translation is needed. Therefore,
>>>>very physical relationship of E.164 addressing scheme (e.g., knowing
>>>>and NXXs, one can find the distance) has been broken.
>>>I was under the impression that finally (after several weeks of
>>>discussion) we'd reached closure on this in last Thursday's call.  The
>>>solution that I understood had been agreed came in two parts:
>>>1. Mobile IP solves most of the problem for us - E.164 number resolves
>>>an IP address which may be anywhere in the world at any given moment in
>>>2. If a user wants to move (and take their number with them) to being
>>>an administrative domain with an otherwise reasonably contiguous E.164
>>>address space, this is easily handled as follows.  The domain that
>>>"should" (in the hierarchical sense) "own" the number that the user is
>>>keeping holds a record of where to contact the current holder of that
>>>number (which will typically be an entity to which an LRQ message can
>>>>Another example can be 800 numbers where the translation is also
>>>It seemed to be agreed in the call that 800 numbers are not a special
>>>case, but merely an example of number portability.
>>>>In addition, from mobility point of view (device or person) wired (and
>>>>wireless?) environement may also be looked into.
>>>Does this mean anything at all?
>>>>As we go froward, we may consider many of those aspects as pointed
>>>>provide solutions for the H.323 addressing schemes.
>>>I was under the impression that we'd reached closure on most of these
>>>Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
>>>Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks.
>>>Phone:+44 1753 661359  email: cpurvis at

More information about the sg16-avd mailing list