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.

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


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.

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??

Cheers,
Phuah Yee Keat

Arne K. Haaje wrote:

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 the config parameter be binfo=1|2|3 where

1=all (default)?
2=first
3=last

Shall I stick with binfofirst=true, the above, or do anyone have a better solution?




Reply via email to