The protocol is CPA, Content Provider Architecture.
The protocol itself does have some stupid stuffs. Fully agreed that everything is in the UDH, but yet the CPA protocol need separate fields to do the transaction.
Probably I should put it as this:
Kannel should provide a way for the sendsms-user to set whether the splitted messages should be charged multiple times or single time. If such flexibility is given by the protocol and telco.
Cheers, Phuah Yee Keat
Arne K. Haaje wrote:
fredag 13. februar 2004, 03:20, skrev Phuah Yee Keat:
Err... I have got something to say over here... Should this be a telco problem? or a protocol module problem?
For the CPA that I was talking about, it have some sense of transaction for long messages. The difference with this transaction 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, with SOAP, http calls or somethoing else?
I guess this actually is what is the final aim, although the discussion started with having binfo just for the first message 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 in the transaction max_content = same with UDH content_sequence = same with UDH
What protocol is this?
So, the Telco will be clever enough to figure out that the 3 messages are in the same transaction, and will only charge it once.
It can get all this info from the UDH.
Currently, my CPA implementation, extract the information from the UDH, and use it. Since kannel splitting config seems to be global across all the other smsc configurations, and my other telcos configuration needs the splitting.
Hmmm... my conclusion is... this guy is trying to accomplish the same thing that I want to accomplish, but having the new config param binfofirst=1|2|3 does not help in my CPA module. Any better way of doing this??
I am not really sure I understand what you want to do. The data you want is all in the UDH, and Kannel should probably not extend a protocol with something that is not in a protocols specification.
