Hi All,
During testing we are experiencing some different issues with the smsbox
when
using an sms-service and a keyword to return contents of a URL.
See end of mail for trace and a stack trace, the sms box behaviour varies,
it
throws an access violation in the debugger and panics when run outside
Attached an
simple patch to fix a typo in the EMI2 driver, related to wait-ack-expire
behaviour.
Stipe,
please, don't close your wincvs and keep on commiting ;-)
Angel FradejasMediafusión España,
S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32
00Fax +34 91 572 27 08
emi2_wa
Andreas Fink wrote:
>
> Did everyone test this with and without Proxy?
> While using a proxy is exactly the locatio where the host would stay the same.
I have to addmit, no, I didn't test proxy mode.
Andreas, can you do this please. The code is already commited. If
there are problems please rep
On Freitag, März 28, 2003, at 04:33 Uhr, Stipe Tolj wrote:
Angel Fradejas wrote:
Current http.c does not follow 302 Location redirections at all. I
tracked down the problem down to the handle_transaction() function.
If we leave trans->host and trans->port set there, there will be no
parse_url()
I did not test with proxy, to be frank
Could you do test that Andreas?
/Angel
-Mensaje original-De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]En nombre de Andreas FinkEnviado
el: viernes 28 de marzo de 2003 16:46Para:
[EMAIL PROTECTED]Asunto: Re: [PATCH] [BUG] http.c
Angel Fradejas wrote:
>
> Current http.c does not follow 302 Location redirections at all. I
> tracked down the problem down to the handle_transaction() function.
>
> If we leave trans->host and trans->port set there, there will be no
> parse_url() for the redirection, and the original url is fet
> > So smsbox could be the default --with-server and one could turn it off
with
> > --without-server = smsbox
>
> hmm, may be an option.
I like the thoughts.
I know for us personally I always compile the wapbox binary and never use
it. The suggestion of having a /gateway/box directory (on the lin
What I should have said was:
The incorrect smsc group is being used by the sendsms-user.
So, should send to , in fact it sends to smsc group
, and is rejected as the ton values are incorrect.
Please help!
Rory
On 28/03/03, Rory Campbell-Lange ([EMAIL PROTECTED]) wrote:
> I have two send-sms us
Hi,
it's simple , because bearerbox make "load balancing" :)
just add allowed-smsc-id or denied-smsc-id for each smsc group...
hope this help...
On Friday 28 March 2003 15:47, Rory Campbell-Lange wrote:
> I have two send-sms user accounts, each sending to a different SMSC (the
> same remote SM
I have two send-sms user accounts, each sending to a different SMSC (the
same remote SMSC with different ton settings for each).
Help gratefull received!
Rory
Kannel version 1.3.1
smsbox shows the corrent send-sms account registered:
INFO: smsbox: Got HTTP request from <127.0.0.1>
INFO:
Here is smsbox log. original message I've sent was: 99182418*t t t t
and curillic letter on the end. You can see that '@' sign was added
before all characters.
2003-03-28 18:16:02 [4] INFO: Starting to service <@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROT
Nothing wrong there, data_coding is set to 8 in bearerbox. Maybe you can
provide the smsbox log to see what it's getting there.
Angel Fradejas
Mediafusión España, S.A.
[EMAIL PROTECTED]
www.mediafusion.es
Tel. +34 91 252 32 00
Fax +34 91 572 27 08
-Mensaje original-
De: [EMAIL PROTECTED]
Angel Fradejas wrote:
>
> Current http.c does not follow 302 Location redirections at all. I
> tracked down the problem down to the handle_transaction() function.
>
> If we leave trans->host and trans->port set there, there will be no
> parse_url() for the redirection, and the original url is fet
Nice to hear.
I have set mo-recode in smsbox configuration to true (Is it enough??).
Here is pdu dump of deliver_sm with cyrillic characters:2003-03-28
16:58:42 [5] DEBUG: type_name: deliver_sm
2003-03-28 16:58:42 [5] DEBUG: command_id: 5 = 0x0005
2003-03-28 16:58:42 [5] DEBUG: command
Current
http.c does not follow 302 Location redirections at all. I tracked down the
problem down to the handle_transaction() function.
If we leave
trans->host and trans->port set there, there will be no parse_url() for
the redirection, and the original url is fetched again and again
:-(
>Can anybody confirm that mo-recode feature of smsbox working properly?
I'm using it, and "works for me (TM)" :-)
Maybe you should heck if your provider sends you the proper DCS in the MO
for Unicode messages.
Angel Fradejas
Mediafusion Espana, S.A.
[EMAIL PROTECTED]
www.mediafusion.es
Tel. +34
I will make a bug report of this to mantis, resolve, fix and close in
a bunch ;)
Fix will be in cvs in a couple of minutes. Could you please try then
the cvs head tree.
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 8
Hi List,
Can anybody confirm that mo-recode feature of smsbox working properly?
--
David Chkhartishvili
Tel: 995 99 182418
Ok, once more ;)
I'm just checking now document WAP-249-PPGService-20010713-a.pdf,
section 6.1 "Client Address Format":
It seems the specs are *not* consistent, because they say:
wappush-address = ["/"] wappush-client-address ["/"] "@" ppg-specifier
wappush-client-address = "WAPPUSH" "=" client-
to answer this on my own.
The PAP spec does not quote any "must" or "should" be in upper-case.
Even the example in section 12.1. is using this:
so obviously in lower-case.
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsa
> I wonder how many of the Kannel users have built applications in front of
> Kannel and how many just talk to the smsbox interface straight from there
> webpage scripting lang?
I guess a lot of us ;)
> And it is a HTTP server.. We are about to turn our Q, Router, Loadbalancer
> into a FooBox and
Ok, I checked this:
When I use your PAP document
>
> "http://www.wapforum.org/DTD/pap_1.0.dtd";>
>
> push-id="235http://127.0.0.1:8080/wappush104871366918042893839821184112102
> 4" source-reference="" >
> address-value="WAPPUSH=+123456789/[EMAIL PROTECTED]"/>
> bearer="sms"/>
>
>
At 12:07 PM 3/28/03 +0100, Stipe Tolj wrote:
> I like this. These then become separate apps that connect to bearerbox and
> provide some form of API into Kannel (http, smpp, emi, xml over
> socket). This way we could even do an Apache mod.
yep. I was also thinking about "connectivity" to Apache
Ritesh Shah wrote:
> The pi dispatcher of mmsc expects a 200 OK response back along
> with a message-ID, as defined in the WAP specs
can you please quote *exactly* where this can be found in the PPG
specs?!
I'm assuming that there is no such expectation concerning the HTTP
response code. Beware
> I like this. These then become separate apps that connect to bearerbox and
> provide some form of API into Kannel (http, smpp, emi, xml over
> socket). This way we could even do an Apache mod.
yep. I was also thinking about "connectivity" to Apache. What would be
your ideas concerning functi
At 11:52 AM 3/28/03 +0100, Stipe Tolj wrote:
Hi list,
I'd like to keep them in seperated cvs modules. This makes Kannel the
"core" system and if you need server implementations you can "plug-in"
the smppbox or other.
I like this. These then become separate apps that connect to bearerbox and
provi
Hi list,
I'm wondering how (which means in which source directory organization)
we should add new foobox'es (ie. smppbox, emibox, sqlbox, etc.)?!
Those are 'server-side' implementations and use Kannel's internal
message communication to act as an smsbox attached to bearerbox.
I'd like to keep th
Hi All,
I am having problems with PPG.
Following is the explanation told to me by MMSC
Vendor
PPG is not sending the response back in proper
format.
PPG accepts the data in some format other than what
has been defined in the WAP PPG specs.
The pi dispatcher of mmsc expects a 200 OK
resp
Hello All,
can anyone help me in impleneting OTAP..,
regards
vijay
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
29 matches
Mail list logo
