I even had a 6th part of a multipart message delivered about an hour after the first part, but then replying from a premium service a whole hour after the message was sent can only be "embarrassing" for the service, so I might as well reject the message, but yes having it user configurable is the way to go.
And BTW as for bogus SMSC's I have one such SMSC connected to my box that has the length of the UDH within the UDH as the first character, so you can imagine what that does to messages especially multipart messages. I asked a while ago if we can implement a patch for such smsc's in kannel and all I got back was a reply stating that I should shoot the manufactured ... Well I did, but the problem remained ... ;-) Never mind... Dimitris Evmorfopoulos -----Original Message----- From: Andreas Fink [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 09, 2007 10:46 AM To: Δημήτρης Ευμορφόπουλος Cc: [email protected]; Alexander Malysh Subject: Re: [PATCH] Re: MO Concatenation On 09.01.2007, at 08:59, Δημήτρης Ευμορφόπουλος wrote: > So you mean msisdn + refnum + smsc-group-id not smscid ... That is > valid! well group-id seems to be new and I have not looked at this part for a while. but sounds logical. > BTW, what do you think that the time-to-live for each part should > be? We show that anything over 3 minutes is already too much. > 3 minutes doesnt sound that wrong to me. You must consider an incoming SMS from a SIM card where the second part cant be hit because the phone was processing the first part (yes there are still bogous SMSC's out there) so the second part would deliver as retry a few minutes later. This can be even 10 minutes. Maybe make it default to 3 minutes and make it uer configurable. > Dimitris Evmorfopoulos > > -----Original Message----- > From: Andreas Fink [mailto:[EMAIL PROTECTED] > Sent: Monday, January 08, 2007 7:45 PM > To: Δημήτρης Ευμορφόπουλος > Cc: [email protected]; Alexander Malysh > Subject: Re: [PATCH] Re: MO Concatenation > > > On 08.01.2007, at 17:38, Δημήτρης Ευμορφόπουλος > wrote: > >> The triple key is not valid. From personal experience I was getting >> the SMS parts from all SMSC's not the one that transmitted the >> first part only. All the operators I worked with do the same thing. >> So the key should remain msisdn + refnum only. > > msisdn + refnum + smscid. > > multiple SMSC's behaving the same are / must be grouped in the same > smsc-id for DLR consolidation too. > > > > > > > > >
