Re: post-xml issues

Look for DAVI: lines below: (I hate MS-OE)

----- Original Message -----
From: "Tim Kehres" <[email protected]>
To: "Kannel Developers List" <[email protected]>
Sent: Tuesday, September 10, 2002 4:12 AM
Subject: post-xml issues


Hello,

I'm still pretty new to this code, so if I've missed something fairly basic,
if you could just point me in the right direction, I'll go back to searching
the code.  :-)

In the meantime, I'm using the latest cvs build of a few days ago, with a
Wavecom modem and RedHat 7.2.  I've been able to get SMS messages through
OK, and the XML content is properly received through a test cgi running
under Apache.  I've got a few questions however:

Originating Address (OA)
This does not get set in the resulting XML object.  In the smsbox.c code,
the generation of this field is dependent upon trans->send_sender.   Why is
this the case?  Is there any reason we don't want to propogate this
information?    Or might there be a problem in the setting of this value?

DAVI: I've copied that code from regular post and I don't recall why, or
even why we have send_sender defaulted to 0.
DAVI: Anyway, you'll only have a <oa> field if you set my-number in
configuration, as kannel can't know the SIM number.
DAVI: same apply to regular smsc if smsc says it's another thing different
from your short number. but this "bug" happens not only on post-xml, but in
post and get too.


UDH Element
This is also not being generated.  I'm getting ready to dig into the code on
this one, but thought I'd check in case anyone else has already tracked this
one down.

DAVI: the udh tag is beeing generated on EMI2 module, so if it don't work in
at, it's probably an AT bug. Please check if you get any udh when using a
get or regular post


AT Element
This one is not a big deal for what I'm trying to put together, however I
don't understand the generated values.   The time information on both the
system as well as cell phone are accurate, however I get the following in
the generated XML object: Feb 21, 1919, 15:57.20, timezone: 0.

DAVI: again, the value I put in xml is the same as the one putted on another
methods, so it's probably an AT bug :((


My last question actually has little to do with the code but instead the
SMS-XML draft recommendation (draft-koponen-sms-xml-03).  In this draft, it
mentions several elements where there may be incompatibilies between the
GSM, TDMA, and CDMA specification, including PID, DCS, and UDH.  For the
UDH, it cites these differences as reasons for only partial support of this
field.  As kannel has already preformed UDH parsing it would seem desirable
to be able to pass pre-parsed data through the XML object to whatever
applications are on the other side, without having to require then to
duplicate this work.  After all, applications should not normally be
required to be knowledgable about the encoding methods used for the message
transfer.

To facilitate this, while acknowledging potential incompatibilieis between
networks, would it not be possible to extend the SMS-XML recommendation to
include a source network type (GSM / TDMA / CDMA), and then realize that
whatever PID, DCS, UDH, etc. data elements that follow in the object would
be specific to that network type?  At least this way we can isolate the UDH
parsing to a single place, and hopefully simplify the applications that make
use of it.

DAVI: I think I said on documentation that kannel xml format is based on
that draft, but there's some different tags on it, especially the from and
to, when I put the authentication, smsc-id's and service id. but yes, we can
have an parameter on <message> tag to say that this is a kannel specific
message or something.
DAVI: As I needed a XML format to use, I've just borrowed the draft, but
kannel message is alot different from the what's proposed on the draft
document


Anyway, just an idea.....

Best Regards,

-- Tim