Hi Willian,
sorry for the late reply, please find comments/answers inlined.
William Carl schrieb:
Thank you , Stipe tolj. I would like to ask few questions coz i wanted
get clear some points as well . I am not a developer but i wanted to
know exactly what is the perfect design based on kannel architecture.If
every one says Kannel supports for WAP 2.0, how it is done with kannel ,
i do not meant about coding .
1. Can we directly forward ACC packet which passes form GGSN to the
kannel box ? Don't we have a separate radius client or such a program to
handle PDU's ?
Kannel will be either
a) a RADIUS proxy, which means it will receive the UDP packets from the GGSN,
record the data for the MSISDN<->IP mapping and forward the UDP datagram again
to a final RADIUS server.
b) act as the "endpoint" RADIUS server, by not forwarding any packets.
Usually network carriers have a RADIUS server that they want to keep the RADIUS
acct PDUs flow to, so normally a) applies.
2. Then all http and UDP requests goes via the wapbox ?
Yes. The normal Kannel will receive the UDP datagrams in the bearerbox, and
forward to any of the connected wapbox instances. Keep in mind that we have a
"native" load-balancing mechanism, due to the fact that N wapboxes can be
connected to one bearerbox. Unfortunately by using more then 1 wapbox, you get
into trouble for the RADIUS acct proxy PDU handling, since a finished request
may have the MSISDN<->IP mapping in a different instance then the following
request goes to. This architecture drawback was also re-designed in the
Kannel-CG version.
3.while request goes through the wapbox adding MSISDN will be happening
for all udp/wap 1.2.1 requests. like that how can we add MSISDN for
each HTTP requests ?
yes, any passed WTP/WSP session -> HTTP request will resolve the client IP to a
matching MSISDN from the mapping storage, which is a memory based dictionary
hash in the normal Kannel.
The Kannel-CG can use a DB for this, i.e. sqlite3 to share the information
across the instances.
4.If we gonna be used SQUID as our proxy server , what are
configurations has to be done for capture MSISDN?
There is no native config you can use on the normal squid. Kannel-CG includes a
custom squid module that "glues" the Kannel logic to the squid runtime binary to
perform the inter-dependency logic tasks to archive this.
5.Then what would be the relationship between squid and the wapbox ?
squid acts as the HTTP proxy, and in case of Kannel-CG as the RADIUS acct
resolver, as any request, WAP 1.x and 2.0 goes via squid as it's primary cache.
bearerbox+wapbox are the WAP 1.x pre-logic daemons. So you have the following
flow chains:
Case WAP 1.x requests:
phone <-> GGSN <-UDP-> bearerbox <-TCP-> wapbox <-HTTP-> squid <-HTTP-> target
Case WAP 2.0 requests:
phone <-> GGSN <-HTTP-> squid <-HTTP-> target
the squid daemon is essential here, since the incorporated RADIUS accounting
proxy resolving is embedded via the custom module to it.
6.Without having a out of the box solution for WAP 2.0, can't we have
WAP 1.2.1 and WAP 2.0 in a single kannel ??
Kannel does the WAP 1.2.1 stuff, but does not include a HTTP proxy for the WAP
2.0 request handling.
I have been thinking of doing this in Kannel internally when I was re-writing
the whole WAP stack to allow 2.0 requests. But the issue here was: why inventing
something totally new, when there is a standard solution that has been proven to
be highly reliable and performative in the real-world, the squid cache. So the
consequence was to glue them together, which Kannel-CG does.
Stipe
-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------
