RE: SMPP data_sm implementation for MT messages

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?

> >

> > >>

> > >>

> >

>