Re: [Devel] Please permit passing additional parameters to sendsms
Loïc Minier wrote:
Hi,
We had problems delivering the notifications to some stricter SMS-C due
to invalid encoding of the SM. The root cause was incorrect message
class of the SM.
The Kannel source code seemed to show that the message class is
always set to zero in the HTTP interface (sendsms) if not specified
(other interfaces behave differently). The coding / binary flag is
also set to zero by this interface by default (meaning 7-bit /
non-binary). [1]
I now consider sendsms an interface where the defaults are not
specified, so I think it would be best for Mbuni to pass coding and
mclass parameters, but perhaps it's cleaner to offer them as
configuration options?
Anyway, I worked around this by removing ? in:
octstr_format_append(m-sendsms_url,
(from octstr_len(from) 1) ?
?username=%Spassword=%Sfrom=%S :
?username=%Spassword=%S,
user,
pass,from);
... to be able to use:
sendsms-url =
http://XXX:13013/cgi-bin/sendsms?coding=1mclass=1;
in mbuni.conf.
Bye,
[1] I mentionned this to Kannel devel as it seems there's Kannel code
to correctly guess the appropriate coding and perhaps mclass depending
on the presence of an udh.
did someone of use wise guys respond on this? ;)
What is the implication on this for Kannel itself?
Stipe
---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
___
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org
[Devel] Please permit passing additional parameters to sendsms
Hi, We had problems delivering the notifications to some stricter SMS-C due to invalid encoding of the SM. The root cause was incorrect message class of the SM. The Kannel source code seemed to show that the message class is always set to zero in the HTTP interface (sendsms) if not specified (other interfaces behave differently). The coding / binary flag is also set to zero by this interface by default (meaning 7-bit / non-binary). [1] I now consider sendsms an interface where the defaults are not specified, so I think it would be best for Mbuni to pass coding and mclass parameters, but perhaps it's cleaner to offer them as configuration options? Anyway, I worked around this by removing ? in: octstr_format_append(m-sendsms_url, (from octstr_len(from) 1) ? ?username=%Spassword=%Sfrom=%S : ?username=%Spassword=%S, user, pass,from); ... to be able to use: sendsms-url = http://XXX:13013/cgi-bin/sendsms?coding=1mclass=1; in mbuni.conf. Bye, [1] I mentionned this to Kannel devel as it seems there's Kannel code to correctly guess the appropriate coding and perhaps mclass depending on the presence of an udh. -- Loïc Minier [EMAIL PROTECTED] ___ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
Re: [Devel] Please permit passing additional parameters to sendsms
Fixed in CVS. Code will check for the '?' and only add it if missing. I wish all changes were this easy :) There is a whole host of changes that we are working on, including: - DB storage of queue data - OMA MMS conformance in message header lengths - Moving to up-coming Kannel 1.4.1 - WURFL db integration into content adaptation module to name but a few. (Just concluded World Cup has of course not helped speed up work!) I have a list if anyone wants to help or support this. Thanks P. On Jul 13, 2006, at 12:19, Loïc Minier wrote: Hi, We had problems delivering the notifications to some stricter SMS- C due to invalid encoding of the SM. The root cause was incorrect message class of the SM. The Kannel source code seemed to show that the message class is always set to zero in the HTTP interface (sendsms) if not specified (other interfaces behave differently). The coding / binary flag is also set to zero by this interface by default (meaning 7-bit / non-binary). [1] I now consider sendsms an interface where the defaults are not specified, so I think it would be best for Mbuni to pass coding and mclass parameters, but perhaps it's cleaner to offer them as configuration options? Anyway, I worked around this by removing ? in: octstr_format_append(m-sendsms_url, (from octstr_len(from) 1) ? ?username=%Spassword=%Sfrom=%S : ?username=%Spassword=%S, user, pass,from); ... to be able to use: sendsms-url = http://XXX:13013/cgi-bin/sendsms?coding=1mclass=1; in mbuni.conf. Bye, [1] I mentionned this to Kannel devel as it seems there's Kannel code to correctly guess the appropriate coding and perhaps mclass depending on the presence of an udh. -- Loïc Minier [EMAIL PROTECTED] ___ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org ___ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
