First of all, thank you for your help. I'm starting to figure out
things now. I think I'll need to do a lot more of code research before
I come up with anything usable, but now I think I know where to start.

On 2/6/06, Lmwangi <[EMAIL PROTECTED]> wrote:
> Hi,
>  have u scanned the provided for TLVs (Within the spec?) Coz if i
> remember correctly, an SMPP client we used (EMG from
> nordicmessaging.se) supported the use of billing info.....
> Anyway back to your question,
> >1. How do I include this new TLV's on the submit_sm PDU?
>
> From the way i understood it, A pdu is automatically built by a macro.
> The macro (gw/smsc/smpp_pdu.c ~ ln119) sorts of iterates over the
> provided fields (Called by a function which has populated pdu fields
> e.g line ~750 of gw/smsc/smsc_smpp.c ) and creates the pdu.
> The TLV definations can be added here. gw/smsc/smpp_pdu.def
>

I've already did that. I've added the missing TLV's there. I've
grep'ed my way into knowing that they are not defined anyway in
kannel.

Kannel compiled with no problems after that, so I assume I didn't
break anything! (yet) ;)

> 2. How do I add new parameters to the sendsms inteface?
>
> Grep is your friend. It is the most powerful tool you have... Anyway
> look at gw/msg-decl.h. You need to speficy your smsbox (sendsms?)
> param here. Then go edit all functions within the gw/smsbox.c file to
> reflect your changes as necessary
>

I'll do that, thanks. BTW, grep's already my best friend in shellspace! ;)

> 3. How could I _only_ add this TLV's when the parameters are defined?
>
> Macros!  It just builds according to the specified fields. This is
> really not good. IMHO. Your smpp client will be INCOMPATIBLE. with
> other smpp peers
> Here is a patch i just developed for smpp 3.4 submit_multi. Patch it
> against the latest cvs srces and use it as a guide. I hope it will be
> good enough
> http://www.opensource.or.ke/index.php?option=com_content&task=view&id=40&Itemid=26
> I don't want to break things with other carriers, this should only be
> passed to this particular carrier.
>
I'll check your patch thoroughly until I figure out how's implemented,
it looks a littele cumbersome for my poor C skills but I think I can
handle it. It's very well commented, that'll surely  help me.

Thanks again for the help, I'll try to figure out things from here and
I'll cry for help again only if I'm really stuck at some point.

Best regards,

Alejandro.

> On 2/6/06, Alejandro Guerrieri <[EMAIL PROTECTED]> wrote:
> > Dear List,
> >
> > Did anybody read this? Any hints about how to implement it (I don't
> > pretend for anybody to do the job for me!) will be very helpful.
> >
> > At least I need a place to start, I'm not sure about how to code
> > support for additional TLV's.
> >
> > Thank you in advance,
> >
> > Alejandro
> >
> > ---------- Forwarded message ----------
> > From: Alejandro Guerrieri <[EMAIL PROTECTED]>
> > Date: Feb 3, 2006 5:48 PM
> > Subject: Additional TLV's
> > To: "[email protected]" <[email protected]>
> >
> >
> > Dear All,
> >
> > One of the carriers we are working with asked us to send them 4 custom
> > TLV's in order to implement billing services.
> >
> > TAG: MAS_APP_ID, id=0x1401 Integer(2)
> > LENGTH: Length of value in octets // Integer(2)
> > VALUE: 1-255 // C-Octet String
> >
> > TAG: MAS_SVC_ID, id=0x1402 Integer(2)
> > LENGTH: Length of value in octets // Integer(2)
> > VALUE: 1-255 // C-Octet String
> >
> > TAG: MAS_CONT_ID, id=0x1403 Integer(2)
> > LENGTH: Length of value in octets // Integer(2)
> > VALUE: 1-255 // C-Octet String
> >
> > TAG: MAS_SVC_ID, id=0x1404 // Integer(2)
> > LENGTH: Length of value in octets // Integer(2)
> > VALUE: 1-255 // C-Octet String
> >
> > I've been crawling the source and reading the lists archives, and I've
> > found that there's not a simple way to implement it without touching
> > the source code.
> >
> > The question is, how could I implement this on the source code? What I
> > need is to be able to send this 4 TLV's on the submit_sm PDU and
> > ideally I should be able to set the values from the sendsms interface.
> >
> > I already added this to smpp_pdu_opt.def:
> >
> > #define SMPP_mas_app_id                         0x1401
> > #define SMPP_mas_svc_id                         0x1402
> > #define SMPP_mas_cont_id                        0x1403
> > #define SMPP_mas_cont_desc                      0x1404
> >
> > and this to smpp_pdu.def:
> >
> > PDU(mas_app_id,
> >    0x00001401,
> >    HEADER
> >    NULTERMINATED(mas_app_id, 255)
> > )
> >
> > PDU(mas_svc_id,
> >    0x00001402,
> >    HEADER
> >    NULTERMINATED(mas_svc_id, 255)
> > )
> >
> > PDU(mas_cont_id,
> >    0x00001403,
> >    HEADER
> >    NULTERMINATED(mas_cont_id, 255)
> > )
> >
> > PDU(mas_cont_desc,
> >    0x00001404,
> >    HEADER
> >    NULTERMINATED(mas_cont_desc, 255)
> > )
> >
> > I've recompiled and everything seems to be working as before.
> >
> > Am I on the right path?
> >
> > What I think I'm missing (please correct me if I'm wrong is):
> >
> > 1. How do I include this new TLV's on the submit_sm PDU?
> > 2. How do I add new parameters to the sendsms inteface?
> > 3. How could I _only_ add this TLV's when the parameters are defined?
> > I don't want to break things with other carriers, this should only be
> > passed to this particular carrier.
> >
> > Any hints will be thoroughly appreciated. :)
> >
> > Best regards,
> > --
> > Alejandro Guerrieri
> > Magicom
> > http://www.magicom-bcn.net/
> >
> >
> > --
> > Alejandro Guerrieri
> > Magicom
> > http://www.magicom-bcn.net/
> >
> >
>
>
> --
> Article:
> -
>    And an unknown college dropout named Bill Gates, together with his
> partner Paul Allen, wrote a version of the programming language BASIC
> for the Altair, forming a company called Micro-Soft in the process. He
> would later drop the hyphen and the capital S, and make billions of
> dollars.
> --
> Comment:
> +++
> Dammit Slashdot! If you would just drop the capital S, you could be
> making billions of dollars too!
> +++++
> http://slashdot.org/comments.pl?sid=171335&cid=14270286
> +++++++
> www.opensource.or.ke
>


--
Alejandro Guerrieri
Magicom
http://www.magicom-bcn.net/

Reply via email to