Subject: siptel - comment on a possible problem

From: Jon Crowcroft <[email-masked]>
Date: Sun, 14 Dec 1997 17:20:12 +0000

a note from an aside i made in response to a remark from an ETSI
person at the siptel bof....

from the fact that telephony calls are pairs of unidirectional
channels, so that an SIPTEL (Internet Telephony to PSTN gatway) may
have to support assymetric channel conversions (e.g. 
phone -> PC one way and phone -> PC in return) so that the call time
translation of I-Ds must be done for called _and_ calling
party....(this does NOT imply a one-one mapping of i-d spaecs from
E.163 to SIP i-ds though at all  - its at call time, so it can be
dynamic - its based on all kids of factors...

and a more extensive problem.....:

rest of this thread now mves to siptel list....
(as should the h.323 versus SIP skirmish, imho)
------- Forwarded Message

To: [email-masked]
cc: [email-masked]
Subject: siptel billing and gateway location
Date: Fri, 12 Dec 1997 10:06:33 +0000
From: Jon Crowcroft <[email-masked]>

i may have become hyper-sensitized to the problems regulatory
bodies see since being involkved in the UK Office of
Telecommunications (OFTel) oversight on IP  but,
ok - so i think there is a very notty problem that we need to steer
around with gateway location for internet telephony and PSTN
interworking (and this relates to the simplest case, not just the
complexc case of a multiple gateway path made out of pieces of (n IP
hop) internet path and (n exchange hop) pstn path....

in the simple case, we want to find a "best" gateway by some
metric...fit for calling some particlar sip i-d....

lets take the case of an IP host calling an id which has already
mapped to a phone number, so we need to go over a piece of internet to
a gateway, then over a piece of PSTN to the phone....

so (as per Brian Carpenter's wise comment as IAB that we MUST not
specify field values that indicate a choice of business practice) 
a simple way to implement gateway _CHOICE_ is that we specify an opaque
field which is an INDEX to a tariff structure; which tariff structure?
well, the one _each_ ISP's SIPTEL gateways advertise - how they
advertise this tariff structure is COMPLETELY out of scope from
SIPTEL work - could be by fax, email, web, TV advertise, etc....

a tariff structure, note, is not simply a list of price per value of
metric - it could look like this

Tariff for ISP#93's Siptel gateway

Index		Tariff
0		no fee
1 		price = A$ * Volume + B$ * Time + C for call +D
2		price = 23$ per call
3 		price is negotiated thru billing protocol 25
4		price is C + carrier select
5		price is C + ATT long haul + billing protocol 25
etc

and Tariff for ISP#13's Siptel gateway
Index		Tariff
0		price = 6$
1 		Diffie Hellman challenge response for subscription id, then free
2		flat fee per call, but time of day dependant

ok, so then when i do gateway selection, i send 2 things, the phone
number, and the index (based on the assumption that as an Internet
user, i have had access to the tarrif structures, and picked the ISP
of choice, anbd am now just asking for the best gateway (note this
might be hidden behind an aplication the client runs (or asks to run
from time to time) on the tarrif and might be presented as a simple
GUI (e.g. gimme the cheapest, or gimme the least likely to call block,
etc etc)

Ok, so problem statrement time

the reason i want to select gateways is to get choice, but the reason
the ISP wants to give multiple gateways is to load balance (at least).
But to load balance, the gaterways must all exchange the load
information; and if the load information is to be meaningful, it must
be PER metric, and be flooded to all gateways under consideration...
(if we allowed the gasteways to send the metrics to the client over
sip, then one could just move a simpler load metric between servers at
low freqwuency....)

so the problem arises where 
provider 1 is a phone company using
nortel, ericsson, ntt, lucent or other phone ecxchanges newly recoded
to run sip gateways on every line card - these modest devices might
suppport 100,000 simulataneous siptel users

provider 2 is a typical big ISP who buy lots of small boxes (e.g. PCs
with dialogics line cards in) 

provider two sees 2 problems
i) the traffic from flooding might_ be very high to get the
responsiveness of the load balance that is achieved trivially by
provider 1, which is unfair
ii) even if we damp the flooding and use redirect to move siptel users
to lighter loaded gateways, provider 2 would see higher call setup
lantency which is unfair...

middle path
now, we know that in general a lot of phone companies who are ISPs are
also moving to more distributed telephony exchanges anyway, and so one
could just ask them to open up the protocol _inside_ such a
distributed exchange (a la pint, maybe) to allow competitors to use 
the PSTN side load info to distribute provider 2's gateway load!

alternatively ,we could say that if someone chooses to offer scalable
siptel who isn;t a telephone company, well then they should blame the
phone company:-)

alternatively.......?

jon 

when we go to the multihop case, things get better and the y also get
worse....

we could use BGP to exchange state between the siptel gateways, and
use a link monitoring protocol to (and maybe MIB and other siptel
configuration data) to feed into thois, and then use circuit routing
protoc ols on top of this to make the call route decision (crank
back?, trunk routing? random ?)

------- End of Forwarded Message