sungsilnom / jsmpp

Automatically exported from code.google.com/p/jsmpp
Apache License 2.0
0 stars 0 forks source link

ProcessRequestException thrown for a deliver_sm msg, generates an invalid deliver_sm_resp #25

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. throw a ProcessRequestException in the onAcceptDeliverSm handler
2. generated deliver_sm_resp does not have a null message_id octet. 

What is the expected output? What do you see instead?
SMPPSim capture of the generated deliver_sm_resp
2009.04.08 10:03:30 453 INFO    12 : DELIVER_SM_RESP:
2009.04.08 10:03:30 453 INFO    12 Hex dump (16) bytes:
2009.04.08 10:03:30 453 INFO    12 00000010:80000005:00000064:00000003:
SMPPSim generates an exception on this message because the PDU size is
expected to be 17 with the included null message_id byte.
Per the SMPPv34 spec, it should look like:
00000011:80000005:00000064:00000003:00

What version of the product are you using? On what operating system?
jsmpp-2.0.1 on Redhat Linux ES release 4

Please provide any additional information below.
An exception thrown while processing the deliver_sm in
SMPPSessionBoundRX.processDeliverSm0 results in a call to
sendNegativeResponse.  SMPPSession.sendNegativeResponse only generates a
call to PDUSender.sendHeader, so any negative responses that include more
fields than just header fields will not be complete.
sendNegativeResponse should likely use the originalCommandId parameter to
determine the appropriate negative response format.

Original issue reported on code.google.com by dchid...@gmail.com on 8 Apr 2009 at 6:08

GoogleCodeExporter commented 8 years ago
I've been re-reading the spec. I think if the commandStatus is non-zero so the 
PDU body will never be returned 
(the message_id). I read about  this on submit_sm, but the spec didn't mention 
this on deliver_sm.

I'll check it again ASAP.

Thx

Original comment by uuda...@gmail.com on 20 Apr 2009 at 2:59

GoogleCodeExporter commented 8 years ago
I've been checking the code. Normal deliver_sm_resp will return null 
message_id, but when deliver_sm_resp 
return using non-zero command_status, so there is no body part will be returned 
(header only). 

Why do we need message_id after all, since the transaction is rejected. This 
concept comes on submit_sm, and 
this concept will works fine on the deliver_sm.

Original comment by uuda...@gmail.com on 23 Apr 2009 at 6:38

GoogleCodeExporter commented 8 years ago
In SMPP v5 it is definitely the case that the body should be left out when the
command status is non-zero.  There is a single note in the v5 spec stating that.
In SMPP v3.4, however, there are notes along with specific responses stating 
this,
but not for all responses.  As a result of the inconsistencies in the spec, it 
seems
ESME/SMSCs have implemented things based on their interpretations.
The v5 spec confirms this (pg 54)
--------------------------------
However some ESMEs or Message Centers may always include a
PDU body regardless of the command_status being returned. In such 
circumstances, the
receiving ESME or MC should ignore its contents, based on the knowledge that the
original request failed.
--------------------------------
The problem is from the sending side, using jsmpp, I have no control over how 
the
response is sent.  Sending a deliver_sm_resp without the body is an error for 
some SMSCs.
It would be nice if this behavior was configurable in jsmpp. 

Original comment by dchid...@gmail.com on 23 Apr 2009 at 2:01