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
