De : abel adegnon <abelinoko...@hotmail.fr>
Envoyé : samedi 26 mars 2016 07:14
À : devel@kannel.org; annou...@kannel.org; us...@kannel.org
Cc : maxtadot...@gmail.com
Objet : Need help with kannel HTTP SMSC with openssmppbox, sqlbox, custom web
App for b
Good day,
Is there any reason that binfo is not passed to the DLR records? Is there
something that I'm missing here?
Thanks,
--Roman
I just answered an SMPPBox billing issue on the users list.
I think billing shouldn't be an SMPPBox/SQLBox/SMSBox issue but rather
something that handles Kannel itself (i.e. bearerbox).
I think if we implement something like this, the community would benefit
from that a lot. I mean, for every sms
M Amedeo Alaimo wrote:
Dear Devel,
So far I am new to kannel, and like it very much. The dlr escape codes are
giving me problems; however.
I believe the billing information would be %B and the account information
would be %o, and that these two variable can only be seen
on an incomming
Dear Devel,
So far I am new to kannel, and like it very much. The dlr escape codes are giving me problems; however.
I believe the billing information would be %B and the account
information would be %o, and that these two variable can only be seen
on an incomming message.
my group for the smpp
PROTECTED] On Behalf
Of fred
Sent: 25 March 2004 05:38
To: devel
Subject: In support of Billing MT sms
Hullo group,
in support of billing for MT messages, DLR is used ok?! However we found
need to tie a transaction of the posted sms message to the smsbox,
and then the eventual DLR response.
Working
Hullo group,
in support of billing for MT messages, DLR
is used ok?! However we found need to tie a transaction of the posted sms
message to the smsbox,
and then the eventual DLR
response.
Working off verson 1.3.1, added ability to
add
http://10.0.0.3:13013/cgi-bin/sendsms?user=foopass
Arne K. Haaje schrieb:
mandag 16. februar 2004, 20:47, skrev Stipe Tolj:
Arne K. Haaje schrieb:
This patch add support for the binfo and rpi parameters.
looks straight foward. +1 and commited to cvs, even while
physically untested due to lacking CIMD connections.
I forgot to
Arne K. Haaje schrieb:
This patch add support for the binfo and rpi parameters.
looks straight foward. +1 and commited to cvs, even while physically
untested due to lacking CIMD connections.
Stipe
mailto:[EMAIL PROTECTED]
---
thing with the UDH is that if we utilize the UDH data to do
multiple messages, the client will get charged 3 times. While if we
utilize the transaction in the CPA itself, the client will only get
charged one time per transaction.
Does that mean you do the billing transaction outside of Kannel
the UDH data to do
multiple messages, the client will get charged 3 times. While if we
utilize the transaction in the CPA itself, the client will only get
charged one time per transaction.
Does that mean you do the billing transaction outside of Kannel, with
SOAP, http calls or somethoing else
Hi list,
since the discussion of the binfo field brings this up again. We here
at Wapme have been thinking of providing some internal layer in
bearerbox to make MT billing possible.
Now, I know that the group has actually refused to handle billing
aspects within Kannel itself. Most of use had
torsdag 12. februar 2004, 12:37, skrev Stipe Tolj:
Hi list,
since the discussion of the binfo field brings this up again. We
here at Wapme have been thinking of providing some internal layer
in bearerbox to make MT billing possible.
Now, I know that the group has actually refused to handle
On Thursday 12 February 2004 13:43, Stipe Tolj wrote:
Arne K. Haaje schrieb:
Some operators handle billing outside of the transport with stuff like
SOAP. These cases should probably not concern Kannel.
that's the question actually. If the result on the SOAP request is
about
torsdag 12. februar 2004, 14:05, skrev Alexander Malysh:
[snip]
Perhaps it can be enable with some config parameter like
binfofirst=true
makes sense. Since splitting is done within the scope of smsbox.
what's if telco wants binfo only for the last message??
Good question. Should then
febrero de 2004 14:25
Para: [EMAIL PROTECTED]
Asunto: Re: [RFC] MT billing logic layer
torsdag 12. februar 2004, 14:05, skrev Alexander Malysh:
[snip]
Perhaps it can be enable with some config parameter like
binfofirst=true
makes sense. Since splitting is done within the scope of smsbox
so that the
subsequence messages in the transaction would not be charged.
But having binfofirst=1|2|3 does not help in my case. How CPA wants it
is that the billing info is in all the messages, but that each message
will have the following information
transaction_id = same for all the messages
Hi all
Perhaps this is a bit off topic, so my apologies.
I am researching into doing some real time billing type work within
kannel for SMS. Now, the environment is an OPSC from orga systems. I
have very limited docs at the moment but I have stumbled across
something called real time
tirsdag 28. oktober 2003, 14:20, skrev Alexander Malysh:
Hi,
I'm -1 for change of shared.c... sorry but it will not work for at least
smpp module...
Why?
Now that Kannel has support for billing, there should be a policy of how to
handle this problem of billing mulitpart messages
not not only
for the first part, I believe for emi is it equal ...
Now that Kannel has support for billing, there should be a policy of how to
handle this problem of billing mulitpart messages. As implementations may
vary across operator, could perhaps a configuration parameter solve it?
Something
torsdag 16. oktober 2003, 18:33, skrev Stipe Tolj:
Hi list,
I have added a 'binfo' to the Msg sms structure to pass arbitrary
billing identifier/information for MT and MO messages.
In EMI2 we forward the XSer 0c field and in SMPP we forward the
service_type from the deliver_sm.
For MO, we
to date, but my
final change to smsc_cimd2.c may be more controversial.
There is an integer field in the CIMD2 protocol called 62 Status Error Code
that can provide more detail about why a message was not delivered. When
doing MT billing it is necessesary to know if a message failed because
I think it's nice if we could specify billing info using
X-Kannel-BInfo header from sms-service.
I'm not sure about smsc_http.c ... is that correct?
Diff output from latest cvs attached.
definetly +1. Applied to cvs. Thanks a lot.
Stipe
mailto:[EMAIL PROTECTED
What syntax are you using for this field and is it operator specific ?
T-Mobile Germany, at least, are using this field.
--
Ian Cass
Hi Stipe,
In the smsbox/static Octstr *smsbox_req_handle() function, the
binfo argument is passed in but I can't see any assignment of
it into the Msg sms struct - did you miss this in the CVS update ?
For MO, we have now a '%B' escape code for the sms-service to pass
this binfo field into any HTTP requests and for MT we have a 'binfo'
CGI variable in the sendsms interface.
BTW, both have been documented in the user's guide.
Stipe
[EMAIL PROTECTED]
, EMI 4.0 says that fields beyond 0c, which means 0d-ff are
reserved for future use.
0c is explicetly defined to be an billing identifier field.
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf
Tel
27 matches
Mail list logo
