Re: [RFC] MT billing logic layer

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