Re: CIMD2 - DLR not crashing!
Oded Arbel kirjoittaa torstaina, 27. kesäkuuta 2002, kello 21:45:It looks like the driver's fault - the timestamp value for dlr_add is not being generated because the relevant line cimd2_request is commented out : snip next_reply: /*reply = cimd2_get_packet(smsc,ts);*/ reply = cimd2_get_packet(smsc, NULL); if (!reply) goto io_error; /snip I haven't tested it, but the way I see it the first cimd2_get_packet() line should be uncommented and the second line removed Yes, but then we will a dynamic memory leak (for timestamp area in every message). Aarno -Original Message- From: Stefan Cars [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 27, 2002 4:44 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: CIMD2 - DLR not crashing! Hi! I have checked the latest cvs and it is not crashing any more when receiving DLRs on CIMD2. Althogh the DLR is still not working (log below): Maybe it is not a showstopper, but it is indeed something worth looking at. Maybe Andreas could help us out here, I can assist with access to CIMD2 SMSC. /S 2002-06-27 15:40:57 [1] DEBUG: Dumping 0 messages and 0 acks to store 2002-06-27 15:41:03 [6] DEBUG: Looking for DLR smsc=CIMD2:217.174.67.135:9972:globalwire, ts=020627154023, dst=46708443600, type=1 2002-06-27 15:41:03 [6] DEBUG: DLR not found! - Stefan Cars CTO Globalwire Communications Phone: +46 18 10 79 50 Mobile(UK): +44 788 061 36 69 Mobile(SE): +46 708 44 36 00
RE: SMPP dlr reports
The SMPP 3.4 spec indicates that the submit_sm resp should return the message id in hex format. I guess there room for error here - the message_id is defined as a C-Octet String - not explicitly hex or decimal unlike the Delivery Receipt id field unfortunately. Yes you are correct, I forgot that its the 3.3 specification not the 3.4 that specifies that the message ID is in HEX. The receipted_message_id doesn't seem to be supported in kannel. Is anyone getting one back in deliver_sm? If so can anyone provide some indication as to whether it matchs the submit_sm message_id, hex, dec, etc .. ie: whether or not if implimented might help. As the receipted_message_id is 3.4 it should match the message id directly. However that is just my interpretation. I haven't seen any SMSCs using the receipted_message_id parameter yet! I suggest that you may enquire about this on the www.smsforum.net website, this website has a discussion forum for SMPP 3.4 that is very useful. Warm Regards, Michael Mulcahy ANAM Wireless Internet Solutions http://www.anam.com mailto:[EMAIL PROTECTED] +353 1 284 7555 Castle Yard, Saint Patrick's Road, Dalkey, County Dublin, Ireland -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alan McNatty Sent: 27 June 2002 23:55 To: [EMAIL PROTECTED] Cc: Kannel Dev Subject: RE: SMPP dlr reports Thanks for your feedback Michael, The SMPP 3.4 spec indicates that the submit_sm resp should return the message id in hex format. I guess there room for error here - the message_id is defined as a C-Octet String - not explicitly hex or decimal unlike the Delivery Receipt id field unfortunately. The delivery report is typically a deliver_sm message. The necessary information though may be stored in two different formats. The first format has the necessary information in the appropriate smpp fields and the other format has the details formatted in the short message field. For the first format the message id will be in the receipted_message_id field and it should be in hex. The second format specifies the message id in the short message field and it is specified as decimal, a bit annoying to say the least as this is what appears to be mostly used. The receipted_message_id is optional - unfortunately it isn't being populated for me so I'm forced to use the short_message which is defined in .. more detail. Time to follow these up with provider. Cheers, Alan
