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:malys...@googlemail.com] On Behalf Of > Alexander Malysh >> Sent: Friday, November 27, 2009 3:32 PM >> To: Michael Zervakis >> Cc: devel@kannel.org; aguerri...@kannel.org >> 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:aguerri...@kannel.org] > >> >> Sent: Friday, November 27, 2009 12:04 PM > >> >> To: Michael Zervakis > >> >> Cc: devel@kannel.org > >> >> Subject: Re: SMPP data_sm implementation for MT messages > >> > > >> > > >> > >What about using "data=xxxx" instead of "text=xxxx" ? > >> > > >> > >-- > >> > > >> > >Alejandro Guerrieri > >> > > >> > >aguerri...@kannel.org > >> > > >> > > > >> > > > >> > > > >> > >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? > >> > > >> > >> > >> > >> > >> > > >
