Re: WAP Push to T68
Hi, I do not have the phone, so I cannot test it. But there is a thread about some phones demanding a specific dcs (more than binary flag). can you check this ? If this works with other phones, I can patch wapbox accordingly. A On Monday, August 26, 2002, at 02:21 PM, Stephane Pointu wrote: Hi All, I'm trying to send a Wap Push to a mobile. It gets sent but never gets displayed o n the mobile. I have a file named si.txt containing: ?xml version=1.0? !DOCTYPE si PUBLIC -//WAPFORUM//DTD SI 1.0//EN http://www.wapforum.org/DTD/si.dtd; si indication action=signal-high href=http://wap.tf1.fr/; created=2002-08-19T12:26:33Z si-expires=2002-09-21T12:26:33Z TF1 /indication /si and another one named pap.txt containing: ?xml version=1.0? !DOCTYPE pap PUBLIC -//WAPFORUM//DTD PAP//EN http://www.wapforum.org/DTD/pap_1.0.dtd; pap push-message push-id=0001 deliver-before-timestamp=2005-10-31T06:45:00Z deliver-after-timestamp=2001-02-28T06:45:00Z progress-notes-requested=false address address- value=[EMAIL PROTECTED] /address /push-message /pap The command i issue to the ppg is: ./test_ppg -q http://localhost:8080/cgi-bin/wap-push.cgi?username=xxx''password=xxx si.txt pap.txt I can say that it gets sent because in the bearerbox logs i see: 2002-08-26 13:08:10 [5] DEBUG: AT2[nokia]: international starting with + (+336) 2002-08-26 13:08:10 [5] DEBUG: AT2[nokia]: TP-Validity-Period: 24.0 hours 2002-08-26 13:08:10 [5] DEBUG: AT2[nokia]: -- AT+CMGS=110^M 2002-08-26 13:08:10 [5] DEBUG: AT2[nokia]: -- 2002-08-26 13:08:10 [5] DEBUG: AT2[nokia]: send command status: 1 2002-08-26 13:08:10 [5] DEBUG: AT2[nokia]: -- 0051000B913366567902F60004A7600605040B8423F625AE966B65726265726F732E7075 72706C656C6162732E636F6D3A3830383000AF808DB1B48002056A0045C6080C037761702E74 66312E66722F000AC3072002081912263310C307200209211226330103544631000101 2002-08-26 13:08:10 [5] DEBUG: AT2[nokia]: -- ^Z 2002-08-26 13:08:16 [5] DEBUG: AT2[nokia]: -- 2002-08-26 13:08:16 [5] DEBUG: AT2[nokia]: -- +CMGS: 65 2002-08-26 13:08:16 [5] DEBUG: AT2[nokia]: -- OK 2002-08-26 13:08:16 [5] DEBUG: AT2[nokia]: send command status: 0 I imagine that it is received by the mobile but not recognised. Am i missing something? Thanks, Stephane.
RE: SMPP query message: Is Kannel able to do this?
Not currently. its not easy to implement as Kannel will have to remember all the messages it sent through and query on them. it'll also probably load the connection a bit more, which would be a problem for high-load connections. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. QUOTATION, n. The act of repeating erroneously the words of another. -- the Devil's Dictionary / Ambrose Bierce -Original Message- From: Mauricio Ramos [mailto:[EMAIL PROTECTED]] Sent: Monday, August 26, 2002 10:52 PM To: '[EMAIL PROTECTED]' Subject: SMPP query message: Is Kannel able to do this? Hi SMPPers, My concern is regarding the delivery notification. Is Kannel able to query the message state in SMSC in a time interval in case SMSC is too lazy to notify de delivery through deliver_sm? Tnx!
RE: SMPP query message: Is Kannel able to do this?
Ops! Some of my clients doens't do that in their SMSCs (resource saving reasons), ie, they don't retry deliver_sm as frequent as needed sometimes. It can get me in trouble when dealing with high-volatily (expiration) messages, for example, when a sms expires in 10 minutes and the SMSC's delivery_sm doesn't come fast enough. Any suggestion? Tnx. -Original Message- From: Andreas Fink [mailto:[EMAIL PROTECTED]] Sent: segunda-feira, 26 de agosto de 2002 18:53 To: Mauricio Ramos Subject: Re: SMPP query message: Is Kannel able to do this? Hi SMPPers, My concern is regarding the delivery notification. Is Kannel able to query the message state in SMSC in a time interval in case SMSC is too lazy to notify de delivery through deliver_sm? Tnx! no. Yous SMSC should deliver reports in a timewhise manner. -- Andreas Fink Global Networks, Inc. -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address:Global Networks, Inc., Schwarzwaldallee 16, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ e-mail: [EMAIL PROTECTED] -- Member of the GSM Association
RE: [PATCH] Kannel resending old unsuccessful messges after a box restart.BUG?
Hi Oded, A backoff alghorithm would be nice! It sounds like Postifx MTA. But, is there a limit or Kannel would be backing off until forever? Regards. -Original Message- From: Oded Arbel [mailto:[EMAIL PROTECTED]] Sent: domingo, 25 de agosto de 2002 14:58 To: Oded Arbel; Damjan; [EMAIL PROTECTED] Subject: [PATCH] Kannel resending old unsuccessful messges after a box restart.BUG? Hi list. Attached is a patch to introduce configurable throttling delay with backoff. the patch adds another configuration option: 'throttling-delay' that is used as the base delay for a simple backoff mechanism that will simply double the last sleep time and sleep again, if it after sleeping and sending it received another throttling error. Warning - this patch is _not_ tested ! it simply compiles. I would like to have comments on the code, the solution methods and the new configuration option name. testing would be nice too :-) I'll try to find time to upload the changes to a test platform tommorow. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. In shallow waters, shrimps make fools of dragons. -- Chinese Proverb -Original Message- From: Oded Arbel Current CVS version does handle 'Throttling Error' properly by stoping to send messages for a predetrmind time - 15 seconds currently. Thats too much, I'm using my own scripts with a perl SMPP driver, usually I can send some 4 messages as fast as I can send them, and then I get the Throttling Error, I then wait some 0.8 seconds and then continue to send. Actually it depends of the settings your SMPP provider has set-up for your connection. Currently it's set as a compile time option, which you can change - 15 seconds is what O2 required of us in their credentials tests. but I agree it's not the best course. Here at m-Wise we usually do that, since most time we don't think about other people's needs as much as we should, as Andreas Fink pointed out, and we usually put in new features with a compile time option, thinking - If we ever find a provider that requires a different setting - we'll add a configuration option, as it's simple enough. I assure you that it is pure laziness and not because we are bad people :-) If the developers have no objections, I'll implement a run-time configuration option which will default to the compile time option (currently 15 seconds), first thing sunday morn. alternativly - do you think its possible/needed/interesting implementing some kind of exponential backoff mechanism that will start at a small delay and increase it as long as it gets consecutive 'Throttling Errors' ?
RE: [PATCH] Kannel resending old unsuccessful messges after a box restart.BUG?
Currently it'll continue to double the wait time with no upper limit. since I assume that eventually the SMPP server will agree to send a message w/o responding with a throttling error, and the double type can hold enough data to represent time length much longer then a year ( ;- ) then I don't think it's a problem. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. When I was 16, I thought there was no hope for my father. By the time I was 20, he had made great improvement. -Original Message- From: Mauricio Ramos [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 27, 2002 4:06 PM To: Oded Arbel; Damjan; [EMAIL PROTECTED] Subject: RE: [PATCH] Kannel resending old unsuccessful messges after a box restart.BUG? Hi Oded, A backoff alghorithm would be nice! It sounds like Postifx MTA. But, is there a limit or Kannel would be backing off until forever? Regards. -Original Message- From: Oded Arbel [mailto:[EMAIL PROTECTED]] Sent: domingo, 25 de agosto de 2002 14:58 To: Oded Arbel; Damjan; [EMAIL PROTECTED] Subject: [PATCH] Kannel resending old unsuccessful messges after a box restart.BUG? Hi list. Attached is a patch to introduce configurable throttling delay with backoff. the patch adds another configuration option: 'throttling-delay' that is used as the base delay for a simple backoff mechanism that will simply double the last sleep time and sleep again, if it after sleeping and sending it received another throttling error. Warning - this patch is _not_ tested ! it simply compiles. I would like to have comments on the code, the solution methods and the new configuration option name. testing would be nice too :-) I'll try to find time to upload the changes to a test platform tommorow. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. In shallow waters, shrimps make fools of dragons. -- Chinese Proverb -Original Message- From: Oded Arbel Current CVS version does handle 'Throttling Error' properly by stoping to send messages for a predetrmind time - 15 seconds currently. Thats too much, I'm using my own scripts with a perl SMPP driver, usually I can send some 4 messages as fast as I can send them, and then I get the Throttling Error, I then wait some 0.8 seconds and then continue to send. Actually it depends of the settings your SMPP provider has set-up for your connection. Currently it's set as a compile time option, which you can change - 15 seconds is what O2 required of us in their credentials tests. but I agree it's not the best course. Here at m-Wise we usually do that, since most time we don't think about other people's needs as much as we should, as Andreas Fink pointed out, and we usually put in new features with a compile time option, thinking - If we ever find a provider that requires a different setting - we'll add a configuration option, as it's simple enough. I assure you that it is pure laziness and not because we are bad people :-) If the developers have no objections, I'll implement a run-time configuration option which will default to the compile time option (currently 15 seconds), first thing sunday morn. alternativly - do you think its possible/needed/interesting implementing some kind of exponential backoff mechanism that will start at a small delay and increase it as long as it gets consecutive 'Throttling Errors' ?
RE: [PATCH] Kannel resending old unsuccessful messges after a box restart.BUG?
Agreed. I was just strict to an exponential backoff alghorithm. -Original Message- From: Oded Arbel [mailto:[EMAIL PROTECTED]] Sent: terça-feira, 27 de agosto de 2002 12:58 To: Mauricio Ramos; Damjan; [EMAIL PROTECTED] Subject: RE: [PATCH] Kannel resending old unsuccessful messges after a box restart.BUG? Currently it'll continue to double the wait time with no upper limit. since I assume that eventually the SMPP server will agree to send a message w/o responding with a throttling error, and the double type can hold enough data to represent time length much longer then a year ( ;- ) then I don't think it's a problem. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. When I was 16, I thought there was no hope for my father. By the time I was 20, he had made great improvement. -Original Message- From: Mauricio Ramos [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 27, 2002 4:06 PM To: Oded Arbel; Damjan; [EMAIL PROTECTED] Subject: RE: [PATCH] Kannel resending old unsuccessful messges after a box restart.BUG? Hi Oded, A backoff alghorithm would be nice! It sounds like Postifx MTA. But, is there a limit or Kannel would be backing off until forever? Regards. -Original Message- From: Oded Arbel [mailto:[EMAIL PROTECTED]] Sent: domingo, 25 de agosto de 2002 14:58 To: Oded Arbel; Damjan; [EMAIL PROTECTED] Subject: [PATCH] Kannel resending old unsuccessful messges after a box restart.BUG? Hi list. Attached is a patch to introduce configurable throttling delay with backoff. the patch adds another configuration option: 'throttling-delay' that is used as the base delay for a simple backoff mechanism that will simply double the last sleep time and sleep again, if it after sleeping and sending it received another throttling error. Warning - this patch is _not_ tested ! it simply compiles. I would like to have comments on the code, the solution methods and the new configuration option name. testing would be nice too :-) I'll try to find time to upload the changes to a test platform tommorow. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. In shallow waters, shrimps make fools of dragons. -- Chinese Proverb -Original Message- From: Oded Arbel Current CVS version does handle 'Throttling Error' properly by stoping to send messages for a predetrmind time - 15 seconds currently. Thats too much, I'm using my own scripts with a perl SMPP driver, usually I can send some 4 messages as fast as I can send them, and then I get the Throttling Error, I then wait some 0.8 seconds and then continue to send. Actually it depends of the settings your SMPP provider has set-up for your connection. Currently it's set as a compile time option, which you can change - 15 seconds is what O2 required of us in their credentials tests. but I agree it's not the best course. Here at m-Wise we usually do that, since most time we don't think about other people's needs as much as we should, as Andreas Fink pointed out, and we usually put in new features with a compile time option, thinking - If we ever find a provider that requires a different setting - we'll add a configuration option, as it's simple enough. I assure you that it is pure laziness and not because we are bad people :-) If the developers have no objections, I'll implement a run-time configuration option which will default to the compile time option (currently 15 seconds), first thing sunday morn. alternativly - do you think its possible/needed/interesting implementing some kind of exponential backoff mechanism that will start at a small delay and increase it as long as it gets consecutive 'Throttling Errors' ?
Help: memory leak of kannel1.2.0
Dear sir, When I test PPG (kannel1.2.0) using 'test_ppg' tools, I find that memory leak is serious. Would you pls tell me how to solve it? or When will you overcome it? Best Regards, Guanghua Hou UTStarCom Beijing RD
