Re: SMPP data_sm implementation for MT messages

where do you have message_payload extracted to user?

that is simple:

MT(data_sm) -> sendsms?text=ABC&metadata=?smpp?pdu_type=data_sm... -> data_sm.message_payload=ABC
MT(submit_sm) -> sendsms?text=ABC... -> submit_sm.short_message=ABC

MO(data_sm) -> data_sm.message_payload=ABC -> receivesms?text=ABC&metadata=?smpp?pdu_type=data_sm
MO(submit_sm) -> submit_sm.short_message=ABC -> receivesms?text=ABC

If user set for MT text=ABC&metadata=?smpp?pdu_type=data_sm&message_payload=XXX then it's undefined and
we are free to choose which one to use and I would prefer to use text as message_payload...

Hope that's clear.

Thanks,
Alexander Malysh

Am 27.11.2009 um 15:21 schrieb Michael Zervakis:

> 
> Let's assume that we follow Alex's recommendation "meta-data=?smpp?operation=data_sm&..." and if operation is omitted we use submit_sm as default.
> 
> 
> We should clarify what should happen to "text=xxxx" if set and this should affect both submit_sm and data_sm operations as SMPP specs state that short_message and message_payload cannot coexist in a PDU (sm_length should be zero if message_payload is used). I can think of three cases here:
> 
> 1) When "text" has a value and "message_payload" is not set. For submit_sm no need to change anything. For data_sm we append meta-data with message_payload and set the value of "text" to it (example: "text=XXXX&meta-data=?smpp?operation=data_sm").
> 2) When both "text" and "message_payload" have values. For submit_sm operation "text" value is set to null (so "sm_length" is set to 0 and we don't break specs) and we use the provided "message_payload" value. For data_sm operation we simply ignore "text" value.
> 
> 3) When "message_payload" has a value and "text" is not set. Normal case doesn't break specs.
> 
> 
> 
> 
> 
>> -----Original Message-----
>> From: Alexander Malysh [mailto:[email protected]] On Behalf Of 
> Alexander Malysh
>> Sent: Friday, November 27, 2009 3:32 PM
>> To: Michael Zervakis
>> Cc: [email protected]; [email protected]
>> Subject: Re: SMPP data_sm implementation for MT messages
> 
> 
>> Hi,
> 
> 
>> why not just use metadata=?smpp?operation=data_sm&... ?
> 
>> then you can check in smsc_smpp whether submit_sm or data_sm should be used.
> 
> 
>> Whether you have to use message_payload or short_message is 
> implementation details that
> 
>> should not be exported to user interface.
> 
> 
>> Thanks,
> 
>> Alexander Malysh
> 
> 
>> Am 27.11.2009 um 13:00 schrieb Michael Zervakis:
> 
> 
>> > Data_sm PDU cannot contain a short_message field. Actually data_sm 
> contains only TLVs and instead of "short_message" field we should use TLV "message_payload" to send text. As a result text=xxxx is obsolete when sending data_sm PDU. If we use data=xxxx what would be the value of data since all necessary data will be included in "meta-data=?smpp?"  ?
> 
>> >
> 
>> >
> 
>> >> -----Original Message-----
> 
>> >> From: Alejandro Guerrieri [mailto:[email protected]]
> 
>> >> Sent: Friday, November 27, 2009 12:04 PM
> 
>> >> To: Michael Zervakis
> 
>> >> Cc: [email protected]
> 
>> >> Subject: Re: SMPP data_sm implementation for MT messages
> 
>> >
> 
>> >
> 
>> > >What about using "data=xxxx" instead of "text=xxxx" ?
> 
>> >
> 
>> > >--
> 
>> >
> 
>> > >Alejandro Guerrieri
> 
>> >
> 
>> > >[email protected]
> 
>> >
> 
>> > >
> 
>> > >
> 
>> > >
> 
>> > >On 27/11/2009, at 10:00, Michael Zervakis wrote:
> 
>> >
> 
>> > >
> 
>> > >> Data_sm can be used as an alternate of submit_sm when transmitting
> 
>> > >> optional parameters (meta-data) and some carriers require the use of
> 
>> > >> data_sm for MT charging applications.
> 
>> >
> 
>> > >> Since Kannel is not implementing this feature it's a good idea to
> 
>> > >> start a discussion on how this could be implemented.
> 
>> >
> 
>> > >>
> 
>> > >> First of all it's obvious that "static int send_messages()" at gw
> 
>> >
> 
>> > >> \smsc\smsc_smpp.c must be able to differentiate msgs that need to be
> 
>> > >> sent as data_sm.
> 
>> >
> 
>> > >> I can think of two ways to achieve this:
> 
>> >
> 
>> > >> 1) Alter MSG definition to inlcude a new parameter that defines type
> 
>> > >> of message Data or normal SMS
> 
>> >
> 
>> > >> Possible ways to use the new parameter could be the following
> 
>> >
> 
>> > >> /cgi-bin/sendsms?from=1111&to=2222&<new parameter>=data&meta-data=?
> 
>> >
> 
>> > >> smpp?key=value
> 
>> >
> 
>> > >> /cgi-bin/senddata?from=1111&to=2222&meta-data=?smpp?key=value
> 
>> >
> 
>> > >> 2) Leave MSG definition untouched and use meta-data to mark msg as
> 
>> > >> data
> 
>> >
> 
>> > >> /cgi-bin/sendsms?from=1111&to=2222&meta-data=?smpp?<new
> 
>> > >> parameter>=data&key=value
> 
>> >
> 
>> > >>
> 
>> > >> Finally a new function has to be defined at gw\smsc\smsc_smpp.c to
> 
>> > >> build data_sm pdu from msg for example "static SMPP_PDU
> 
>> > >> *dmsg_to_pdu(SMPP *smpp, Msg *msg)"
> 
>> >
> 
>> > >> and function "static int handle_pdu()" at gw\smsc\smsc_smpp.c has to
> 
>> > >> be modified to include a case for data_sm_resp PDU.
> 
>> >
> 
>> > >>
> 
>> > >> Any comments?
> 
>> >
> 
>> > >>
> 
>> > >>
> 
>> >
> 
>