Yup, we are heading to next telepath rel. Hope this is fixed.
The incativity timeout is set, we use this because if the
network link ever goes down for a few seconds, the procesess
atending the ESME keeps on running on the SMSC, thus any
further BIND from the ESME would be useless until
this process is either killed or die with the timeout.
On Wed, 15 May 2002, Mauricio Ramos wrote:
> I've seen this problem happening with Logica and some guys told me it was
> solved with a new version of Telepath. I also heard it could be related to
> SMSC's smpp inactivity timeout, not sure.
>
> -----Original Message-----
> From: dominguez herrera sergio andres [mailto:[EMAIL PROTECTED]]
> Sent: terça-feira, 14 de maio de 2002 19:17
> To: Damjan
> Cc: [EMAIL PROTECTED]
> Subject: Re: Kannel SMPP (Comverse SMSC)
>
>
>
> I had the same problem as you guys!
>
> Its seems LOgica does not recognize enquire_link
> and enquire_link_resp as significant traffic and shuts
> down the link without mercy.
>
> There is suppose to be a -t option that makes
> Logica's AIM send an enquire_link by itslef
> but the connection was being droped anyway.
>
> The quick and dirty workaround we found was
> making the ESME to send a "dummy" message
> to the SMSC. The message should have the
> destination TON/NPI set as the TON/NPI assigned
> to the ESME.
>
> Ths way, the message is sent back to the ESME
> on the receiver link, avoiding it to go down
> after the idle Timeout.
>
> It is kinda enquiring the link but the message
> response comes through the receiver...
>
>
> On Wed, 15 May 2002, Damjan wrote:
>
> > > I'm curious to know how you could "see" that Kannel sent and
> enquire_link
> > > PDU. Sometimes it helps.
> >
> > In the kannel source code, there is a file "gw/smsc_smpp.c".
> > At the start of this file there's "dump_pdu" function, which is
> > enabled by changing "#if 1" to "#if 0".
> >
> > Rebuild your kannel and you'll have a dump of all PDUs in the
> > "bearrer.log".
> >
> >
> > > Going to your problem, I have a similar behaviour with Logica SMSC and
> the
> > > problem was solved when the idle timeout of the SMSC was increased.
> That
> > > means the SMSC was waiting PDUs for a time shorter than the Kannel was
> > > senting PDUs. I didn't see a way to do the inverse configuration on
> > > Kannel's side, but would be good, if possible.
> >
> > I have successfully connected to the same SMSC as a "bind_receiver" with
> > a perl program, and it works very well. It's strage that the
> > "transmit" part of kannel works ok.
> >
> >
> >
> >
>
>
