Quoting Andreas Fink <[EMAIL PROTECTED]>: > > Furthermore, I find that solution not very clean. Would not it > >be better to correct the keepalive behaviour in the case of the presence > of > >receive-port ? In fact, if receive-port is present, it means that another > >connection is used for MO so the keepalive should only take MT in account > >since it will send UCP31 only on it. Right ? > > > UCP31 is done on MT and MO
If UCP Alert packages are not supported on MT only connection (through the receive port), the code should be changed to not send it through that connection. Can please somebody patch it (it should be simple) because I don't have a chance now ? > >BTW, does it mean that it is preferable to have bi-directional UCP > >connections ? > > there are no bidirectional UCP connections! WHAT? I only have one tcp connection, opened from kannel to the smsc, and because the smsc wants to have my kannel port locked, I have to have keepalive ucp packets to keep the connection alive, or else the connection drops and stays 1 minute in time_wait state. But I do everything with only one tcp connection. It's totally assynchrounous. When a message arrives to the smsc, it delivers the message to kannel even without me sending the alert ucp command. Of course you can have one connection started by you (kannel) when you want to send a message (and while it's connected, you can receive throught it too), and when it timesout and a new message arrives to smsc, it's it that connects to you. But my operator doesn't like to open connections back, So I'll have to keep my own alive all the time. And I like it > > if you want to send messages the client (kannel) does always connect > to the SMSC. > if you want to receive messages, you can either poll for it by > connecting a second session or you can have the SMSC call you. In any > case you will have a sending session and a receiving session. > > Keepalive is only done on sessions Kannel is issuing (opening). > On sessions initiated from the SMSC side, it would be up to the SMSC > to issue a keepalive (but frankly it doesnt make too much sense). > > > -- > > Andreas Fink > Fink-Consulting > > ------------------------------------------------------------------ > Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 > Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland > E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com > ------------------------------------------------------------------ > Something urgent? Try http://www.smsrelay.com/ Nickname afink > > -- Davi
