UCP/EMI Delivery reports | Search |
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through September 15, 2006 ⬆ |
◄ ► |
Author | Message | |||
dinos New member Username: Dinaras Post Number: 7 Registered: 02-2006 |
Hello, I have a UCP/EMI SMSC configured in my Nowsms v5,51 with latest patch. Talking with my provider he said that in order to receive dlr from UCP/EMI i have to make the following settings in order to receive the Delivery Report via UCP, you should set the parameter NRq=1 (Notification Request) and the parameter NT=7 (Ntification Type). Please note the parameter NAdC must be empty. Is this possible with nowsms Thank you very much in advance Kind regards Konstantinos Liadakis | |||
YamyNg New member Username: Yamyng Post Number: 5 Registered: 04-2004 |
TrackSMPPReceipts=Yes for SMPP how about UCP/EMI ? | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6112 Registered: 10-2002 |
(Note: TrackSMPPReceipts=Yes is enabled by default for NowSMS 2006. It is not necessary to explicitly set this parameter.) Regarding UCP/EMI delivery receipts, we do not currently have a live connection to a UCP/EMI provider that supports delivery receipts. So we can't do any testing. We could certainly implement support for delivery receipt tracking in the UCP/EMI environment, similar to what we have implemented for SMPP and GSM modem connections. But we would need someone that could provide us feedback on whether or not it is working properly. If you could help provide this feedback, let me know, and we'll see if we can get the development process started. -bn | |||
YamyNg New member Username: Yamyng Post Number: 6 Registered: 04-2004 |
Below is example of NowSMS send to UCP/EMI SMSC 21/00369/O/51/09224584923/2877/////////////////3//312F3320546F206163636573732079 6F7572206163636F756E742C207265706C792077697468204D595641554C5420494E203C50617373 776F72643E2E20466F72207370656369666963204D795661756C742048454C5020746F706963732C 2073656E642074686520666F6C6C6F77696E67206B6579776F72647320746F20323837373A////// ////0C12303130303030303143313233303030303630///0D For the NRq=1 just add 1 in the field number 8 : 21/00369/O/51/09224584923/2877//1/..... Everything is same, so if want test just send me the modified file of smsucp.dll I will tell you the result after I test with the UCP/EMI SMSC. | |||
YamyNg New member Username: Yamyng Post Number: 7 Registered: 04-2004 |
For the NT=7 all(BN+DN+ND) add 7 in the field number 10 : 21/00369/O/51/09224584923/2877//1//7/..... | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6131 Registered: 10-2002 |
Hi, Thanks for the information ... adding the parameters to request the delivery receipt is the easy part. We also need to add logic to receive and parse the delivery receipt. That part requires updates to the interface between SMSUCP.DLL and the main part of NowSMS. But we'll give it a try. I've uploaded an update to try ... http://www.nowsms.com/download/ucp2006.zip This update can only be used with NowSMS 2006. Attempting to use it with older versions will only result in crashes. If you edit SMSGW.INI, and add TrackUCPReceipts=Yes under the [SMSGW] header, NowSMS will enable receipt handling for UCP/EMI connections, and ... if it all works properly ... convert the delivery receipts into SMPP format. -bn | |||
YamyNg New member Username: Yamyng Post Number: 8 Registered: 04-2004 |
Hi, I will try it and let you know the results within these few days ... | |||
YamyNg New member Username: Yamyng Post Number: 9 Registered: 04-2004 |
Hi Bryce, The UCP debug log below : 16:18:06:000 DumpPacket: 105 byte packet 16:18:06:000 DumpPacket: 02 30 32 2F 30 30 31 30 33 2F 4F 2F 35 31 2F 30 02/00103/O/51/0 16:18:06:000 DumpPacket: 39 32 32 34 37 35 37 35 30 36 2F 32 38 37 37 2F 9224757506/2877/ 16:18:06:000 DumpPacket: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F //////////////// 16:18:06:000 DumpPacket: 33 2F 2F 35 34 36 35 37 33 37 34 36 39 36 45 36 3//54657374696E6 16:18:06:000 DumpPacket: 37 32 30 36 44 36 35 37 33 37 33 36 31 36 37 36 7206D65737361676 16:18:06:000 DumpPacket: 35 32 30 34 36 34 46 34 33 2F 2F 2F 2F 2F 2F 2F 520464F43/////// 16:18:06:000 DumpPacket: 2F 2F 2F 2F 2F 2F 32 37 03 //////27 16:18:06:718 ParseUCPResponse: 02 16:18:06:718 ParseUCPResponse: R 16:18:06:718 ParseUCPResponse: 51 16:18:06:718 ParseUCPResponse: A 16:18:06:718 ParseUCPResponse: ucpReturnSequenceNumber = 2, ucpReturnOriginatorOrResponse = R, ucpMessageCode = 51, ucpReturnAckOrNak = A, ucpReturnError = 0 16:18:06:718 DumpPacket: 46 byte packet 16:18:06:718 DumpPacket: 02 30 32 2F 30 30 30 34 34 2F 52 2F 35 31 2F 41 02/00044/R/51/A 16:18:06:718 DumpPacket: 2F 2F 30 39 32 32 34 37 35 37 35 30 36 3A 30 34 //09224757506:04 16:18:06:718 DumpPacket: 30 37 30 36 31 36 31 38 30 32 2F 37 38 03 0706161802/78 16:18:06:718 UCPSubmitMessage: Got a UCP response 16:18:06:718 ParseUCPResponse: 02 16:18:06:718 ParseUCPResponse: R 16:18:06:718 ParseUCPResponse: 51 16:18:06:718 ParseUCPResponse: A 16:18:06:718 ParseUCPResponse: ucpReturnSequenceNumber = 2, ucpReturnOriginatorOrResponse = R, ucpMessageCode = 51, ucpReturnAckOrNak = A, ucpReturnError = 0 After I patched the ucp2006.zip and added the TrackUCPReceipts=Yes under the [SMSGW] header and restart nowSMS but ..../O/51/09224584923/2877//1//7/..... the 1 and 7 is still not included in the UCP post. | |||
YamyNg New member Username: Yamyng Post Number: 10 Registered: 04-2004 |
From emi_ucp_specification_v46-5232006.pdf NRq Length : 1 Type : Num.Char. Meaning : Notification Request Value - 0 : NAdC not used 1 : NAdC used NT Length : 1 Type : Num.Char. Meaning : Notification Type Value - Buffered message notification (BN), Delivery Notification (DN), Non-delivery notification (ND), 0 : default value 1 : DN 2 : ND 3 : DN+ND 4 : BN 5 : BN+DN 6 : BN+ND 7 : ALL May be under [UCP] header can add 2 more option UCPNRq=? default value is 1 UCPNT=? default value is 7 Both only work when TrackUCPReceipts=Yes | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6162 Registered: 10-2002 |
Hi, That probably means that no receipt was requested when the message was submitted. (Unless we made some other mistake.) When submitting via HTTP include "&ReceiptRequested=Yes" in the URL request. Or you can edit SMSGW.INI, and under the [SMSGW] header, add ReceiptRequested=Yes ... if you add this INI parameter than it is assumed that a receipt is requested for all messages submitted via HTTP. -bn |