H.323 Addresses

Pete Cordell pete.cordell at BT-SYS.BT.CO.UK
Thu Sep 3 10:09:38 EDT 1998


Douglas,

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.

Regards,

Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell at bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================


>----------
>From:  Douglas Clowes[SMTP:dclowes at OZEMAIL.COM.AU]
>Sent:  03 September 1998 02:57
>To:    ITU-SG16 at MAILBAG.INTEL.COM
>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
>process.
>
>In the context of the caller, a destination address may be an
>"internal"
>form like an abbreviated dialing number (*21), a service prefixed
>number
>(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
>subject
>to resolution in the context of the callee. I think that 800 numbers
>are
>like this. Since geographical information is probably not known about
>the
>source or the destination, much less path metrics between them,
>factoring
>that into the resolution may be a problem. The result of this stage is
>an
>effective address.
>
>If the response is a prioritised sequence of endpoints, then the source
>can
>select from the endpoints within each priority based on
>characteristics.
>For example 1-800-555-1212 => (1-415-555-1212, 1-212-555-1212) and I
>can
>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
>address.
>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
>RSVP.
>
>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
>are
>often distance independent.
>
>What's more likely to be interesting, is the moving call centre where
>the
>effective address follows the sun from London to San Francisco to
>Sydney to
>maximise daytime staff utilisation. Here your 1-800 number will
>translate
>to 44-171, 1-415, and 61-2 depending on the time of day.
>
>Regards,
>
>Douglas
>
>At 18:01 02/09/98 +0100, Chris wrote:
>>All,
>>
>>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.
>>
>>Regards,
>>Chris
>>----------------------------------------
>>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 madge.com
>>
>>--------------------------------
>>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!!!
>>
>>Regards,
>>
>>Pete
>>=================================
>>Pete Cordell
>>BT Labs
>>E-Mail: pete.cordell at bt-sys.bt.co.uk
>>Tel: +44 1473 646436
>>Fax: +44 1473 645499
>>=================================
>>
>>
>>>----------
>>>From:  Chris Purvis WVdevmt-WS[SMTP:cpurvis at MADGE.COM]
>>>Sent:  02 September 1998 13:09
>>>To:    ITU-SG16 at MAILBAG.INTEL.COM
>>>Subject:       Re: H.323 Addresses
>>>
>>>Radhika,
>>>
>>>>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,
>>>3.
>>>>URL, and 4. TCP/UDP/RTP port addresses (and 5. aliases as well I
>>guess).
>>>>
>>>>Although a hierarchical notion of addressing scehmes have been
>>>discussed, we
>>>>have also recognized that some other variations of addressing schemes
>>>are
>>>>there.
>>>>
>>>>For example, people change their physical locations, but they might
>>have
>>>to
>>>>keep the same E.164 addresses. So, a translation is needed. Therefore,
>>>the
>>>>very physical relationship of E.164 addressing scheme (e.g., knowing
>>>NPAs
>>>>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
>>>to
>>>an IP address which may be anywhere in the world at any given moment in
>>>time.
>>>2. If a user wants to move (and take their number with them) to being
>>>in
>>>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
>>>be
>>>sent).
>>>
>>>>Another example can be 800 numbers where the translation is also
>>needed.
>>>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
>>above
>>>to
>>>>provide solutions for the H.323 addressing schemes.
>>>I was under the impression that we'd reached closure on most of these
>>>already.
>>>
>>>Regards
>>>Chris
>>>----------------------------------------
>>>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 madge.com
>>>
>>
>>
>



More information about the sg16-avd mailing list