Re: smsbox closed connection (at2)

Andrea Viscovich wrote: > > Something very very bad happens sometimes with smsbox. > This isn't the first time it happens > Don't really know why, but it closes connection. > Maybe it's because it receives an empty sms, but > I have omit-empty = true in sms-service group. > I give you here all th

Re: Kannel and RTTTL format?

Patrick Mignott wrote: > > hi all, > can kannel support RTTTL data format or do you have to convert to > HEX? in general, we don't want Kannel to be too application specific. So you are considered to do most of the application transcoding (in your case RTTTL to UDH hex) on your own out of Kannel

Re: Contributions... generic NACK info and throttling

> Also, I might like to implement a per SMSC throttling code... because our > SMPP SMSC only allows 25 messages / sec... which means that if messages get > queued up and/or stored to file... bearerbox can continuously attempt to > overload the SMSC should the queue become large or should it reload

Precedence of faked-sender, global-sender, from

I'm currently working on my patch for smsc default-sender and forced-sender, and I just noted that existing config directives faked-sender and global-sender are treated by smsbox in different ways.   With MT-replies, precedence is: first faked-sender, second global-sender and third the MO r

smsbox_req_sendota broken?

No testing at all, just rushing through the code to add support for the conig directives I'm working on but I'd say this function is broken.   We have no initialization for Msg* msg, no msg_create at all.   I cannot test SMS OTA, so maybe someone with the resources available for this please

Re: Contributions... generic NACK info and throttling

Alex Judd wrote: > > BTW did we add the ton/npi configuration file changes for the SMPP driver > to CVS yet? I can add the other configuration changes at the same time. no it's yet not incorporated to cvs. It seems the pro and cons discussion isn't leading us to something valueable. So, if you

Re: smsbox_req_sendota broken?

Angel Fradejas wrote: > > No testing at all, just rushing through the code to add support for > the conig directives I'm working on but I'd say this function is > broken. shouldn't be borken, AFAIK. > > We have no initialization for Msg* msg, no msg_create at all. Ok, now I remember, I have be

RE: TON and NPI

Hi All, The TON and NPI parameters are defined according to the GSM and the SMPP standards. Unfortunately how they are used in an SMSC does not seem to be standardised. I have seen people using different values to achieve the same functionality using different SMSC implementations. This is also

Re: smsbox closed connection (at2) (null msgdata)

> Unfortunatly our cvs checkout is not up to date so I don't see what is > happening on *your* line 698 of smsbox.c. The current cvs is out of > scope for url_result_thread() for this line number. > > Could you please copy a short passage around that number, or the > url_result_thread() function,

Re: Contributions... generic NACK info and throttling

At 03:42 PM 2/14/02 +0100, you wrote: >Alex Judd wrote: > > > > BTW did we add the ton/npi configuration file changes for the SMPP driver > > to CVS yet? I can add the other configuration changes at the same time. > >no it's yet not incorporated to cvs. It seems the pro and cons >discussion isn't

RE: TON and NPI

> The TON and NPI parameters are defined according to the GSM and the SMPP > standards. Unfortunately how they are used in an SMSC does not seem to be > standardised. Yes - that unluckly is the problem - those of us who have to deal with non-standard implementations of SMPP have to modify the co