Back-End Services (BES) (was: Comments on AT&T proposal)

Douglas Clowes dclowes at OZEMAIL.COM.AU
Sun Aug 23 20:29:38 EDT 1998


At 09:13 21/08/98 +0200, HERSENT Olivier CNET/DSE/CAE wrote:
>Some follow-on comments inserted below :
>
>
>> If you are visiting another IP network, are you asking the GK for more
>> than
>> bandwidth and address resolution (absent BES-based AR).
>--- Yes, for instance if I dial an E164 number, or if I use a high level of
>QoS, I will be billed, probably based on the GK info. Maybe I also have a
>set of short numbers programmed in your home GK, and you would like to use
>them ...

This really does beg the question of "what are the back-end services?". If
these types of services are "Back-End Services" then it is appropriate for
the "visited gatekeeper" to request these services of its _own_ Back-End
Server, rather than try to identify whether they are local or not.

>From the Gateway POV, the services _may_ be provided by the GK, logically.
Although, there does exist a link between the GW and the BES in most diagrams.

>> >recognize from the calling party alias that the terminal si from an
>> external
>> >administation having an agreement with the visited administration.
>> >It would then forward the xRQs to the home gatekeeper of the terminal and
>> >get the xCFs in reply.
>>
>> This proposition requires the calling party alias to identify the "home"
>> administration, and the gatekeeper to be able to resolve the "home"
>> gatekeeper.
>--- Yes, this would be based on the domain name of an email alias. When
>completing a roaming agrement, each party would pass the other party a list
>of domains to include in the agreement. That could be *.francetelecom.fr,
>*.myprefferredcustomer.com, ...

Obviously, the users "home" address needs to be identified. My question is
whether the GK, or the BES, should be doing this. I expect there to be many
more GK than BES.

>Then to identify the GK, the usual DNS TXT record lookup could be used, or
>the parties in agreement could also store some IP addresses.
>The home GK can find who is the visited domain GK from a token inserted in
>the relayed xRQs, or another comvention such as name mangling (source alias
>toto at francetelecom.com modified as
>toto at francetelecom.com!deutschetelecom.com )
>
>This doesn't have to be standardized, it is just added value programming on
>top of the GK.
>
>> >This has many benefits :
>> >- The home GK knows where is the roaming teminal and can forward calls.
>> >- Any policy implemented at the home gatekeeper (restricted phone usage,
>> etc
>> >...) is still enforced in any visited domain
>>
>> So, bandwidth restrictions in the home zone would be enforced in a visited
>> zone?.
>        --- Yes, and many more services. for instance you could be using a
>prepaid account that allows only to call some numbers (your company ...).
>This restriction would be enforced as well in the visited domain.
>        Of course the visited domain can also enforce its own policy,
>because it relays the xCFs. For instance if the home GK allow to call a
>premium rate number, but the local policy does not allow this, then the
>visited GK would simply change the ACF into an ARJ.

Well, No. I don't think that (what I regard as) zonal policies operate
outside a zone. I regard the GK as supporting zonal policy. I regard
Administrative Domain policy as the responsibility of the BES, but that's
the open question.

>> >- It is simple
>>
>> I think we should be looking at Back-End Services, at least so we know
>> what
>> to expect of them, and don't make GK-GK break later, or make GK-BES
>> difficult/impossible.
>--- We are looking into this. So far the main restriction we see in existing
>toolkits for this type of GK/GK services is that they are sometimes unable
>to initiate RAS/Q931 messages (no API to send an xRQ). Hopefully this will
>be improved in future versions.

I don't understand this. Or at least, how it relates to Back-End Services.

>We plan to bring this work to ITU/ETSI as soon as we have something that
>seems flexible enough to build most services.
>

>From my point of view, gatekeepers should be responsible for policies and
actions that relate to their zone of influence. Things that extend beyond a
gatekeeper's zone, are candidates for the Back-End Services.

Using the above example, abbreviated dialing, that should be the same as I
move from zone to zone. It should be dependent on who I am, not where my
home zone is. If I transfer, within my company, from one zone to another,
should my identity change for my new home gatekeeper? Should my abbreviated
dialing list change? I don't think so.

I think that Back-End Services should be able to support traditional AAA,
as it applies. This includes user-identification, and therefore roaming.
This does not preclude this occuring at the gateway by utilising RADIUS,
for example.

I think that BES should support address translation. This would include
both abbreviated dialling, plus prefix stripping and interpretation (e.g.
international access codes, like 011). By allowing the translation to
return any alias address, including transport addresses, it could also
support gateway location.

I think that the BES should be able to support call detail recording,
accounting, billing and settlement services.

If all of that is acceptable, as the province of Back-End Services, how
does it affect the Gatekeeper-to-Gatekeeper Communication and the
Communication between Administrative Domains? Quite substantially, I would
have thought.

So, even if we don't yet define the protocols to operate between H.323
elements and the BES (at reference point D), I think it would be
constructive to determine what's in there, and is therefore _not_ between
gatekeepers (at reference point C).

Regards,

Douglas



More information about the sg16-avd mailing list