> > hmmm, sounds like our smppbox you are talking about?! ... you didn't > steal it from us Paul, did you? ;)) >
No, but it might've worked better if I did... > Ok getting back serious. So this is a SMPP server (or at least) SMPP > proxy, right? Yes. > ok, that's an argument that can hold. If we consider proxying an > submit_sm PDU via a chain like this: > > [submit_sm] -> SMPP proxy -> [Msg] -> bearerbox -> [submit_sm] -> > SMPP server > > then I do agree to Paul that the data coding values should be > transparently delivered to the submit_sm PDU that goes it's way out of > bearerbox. Yes, that's exactly the use case. > > Is it possible that we miss some other SMPP specific fields that come > into account while re-converting back again to submit_sm PDU? > Nothing more that I can see (so far...)
