Aarno Syvänen
2001-08-29 12:51:58 UTC
Hi List,
Kannel needs configuration variables for WAP push. Following expalnation
may be useful:
WAP push is a two part process: a content server sends SI (or SL)
document containing, for instance, an
url, to the phone, and, after the user has accepted, the phone pulls the
content in question (random push
messages would detoriate user experience).
This means, at least for now, the content provider sends SI over SMS and
the phone does the pull over
GPRS.
Essentially this means that wapbox will do a SMS push, exactly same way
smsbox does now. (The code for
this is already mostly written.) If needed, wapbox will do segmentation
and send each part of the message separately. There is no need to route
*incoming* WAP over SMS packets.
There is no need to add new message type to Kannel internal protocol,
sms will do fine, even though
some flags are allways turned on or off. (Wapbox will send a normal 8bit
message using unicode, having
an udh, without need of segmentation.) Internally, fields needed for
constructing sms message are passed to
wdp layer from ppg as wapevent fields.
Bearerbox must, of course, accept sms messages from wapbox and route
them to the sms centers.
Note that pap document sended to ppg by pi contains many control
variables: receiver (the phone number), udh-data (the client port for
WAP push, essentially), validity period and deferred flag.
I think we need following configuration variables (suggestions are, of
course, very wellcome):
For core group: we need a separation flag for WAP push service, so that
bearerbox would not ask smsbox
group.
For smsc connections: an url telling where a confirmation (for instance,
a HTTP reply), or even better, a
delivery report, are to be sended. Perhaps we need both (delivery
reports are not allways available ?)
There is no need for username or password here, because ppg will have
these as its configuration variables.
This, too, depends on wap-push-flag.
For wapbox, a new group for configuring a ppg server, this being a
separate service. Note that pi sending requests may have authenticated
them, so a flag for a trusted network is needed, in addition of normal
Kannel IP authentication. Other configuration variables are username and
password (if the network is not trusted), http-port, concurrent-pushes,
default-smsc, forced-smsc and faked-sender. (IP authentication is
already mentioned)
Aarno
Kannel needs configuration variables for WAP push. Following expalnation
may be useful:
WAP push is a two part process: a content server sends SI (or SL)
document containing, for instance, an
url, to the phone, and, after the user has accepted, the phone pulls the
content in question (random push
messages would detoriate user experience).
This means, at least for now, the content provider sends SI over SMS and
the phone does the pull over
GPRS.
Essentially this means that wapbox will do a SMS push, exactly same way
smsbox does now. (The code for
this is already mostly written.) If needed, wapbox will do segmentation
and send each part of the message separately. There is no need to route
*incoming* WAP over SMS packets.
There is no need to add new message type to Kannel internal protocol,
sms will do fine, even though
some flags are allways turned on or off. (Wapbox will send a normal 8bit
message using unicode, having
an udh, without need of segmentation.) Internally, fields needed for
constructing sms message are passed to
wdp layer from ppg as wapevent fields.
Bearerbox must, of course, accept sms messages from wapbox and route
them to the sms centers.
Note that pap document sended to ppg by pi contains many control
variables: receiver (the phone number), udh-data (the client port for
WAP push, essentially), validity period and deferred flag.
I think we need following configuration variables (suggestions are, of
course, very wellcome):
For core group: we need a separation flag for WAP push service, so that
bearerbox would not ask smsbox
group.
For smsc connections: an url telling where a confirmation (for instance,
a HTTP reply), or even better, a
delivery report, are to be sended. Perhaps we need both (delivery
reports are not allways available ?)
There is no need for username or password here, because ppg will have
these as its configuration variables.
This, too, depends on wap-push-flag.
For wapbox, a new group for configuring a ppg server, this being a
separate service. Note that pi sending requests may have authenticated
them, so a flag for a trusted network is needed, in addition of normal
Kannel IP authentication. Other configuration variables are username and
password (if the network is not trusted), http-port, concurrent-pushes,
default-smsc, forced-smsc and faked-sender. (IP authentication is
already mentioned)
Aarno