Discussion:
UCP01 instead of UCP51 ?
b***@gmx.net
2000-06-02 12:34:10 UTC
Permalink
I am connected via TCP/IP connection to the CMG SMSC (UCP). I have traced
the data in the pakets which are sent to the SMSC. UCP51 is used to send the
paket. The problem is that this doesn't work with the SMSC. I have tested
with another software and it is using UCP01 and it works perfectly.

My question now is:

Is it possible to send with UCP01 instead of using UCP51 (I know that
UCP01 should be used any longer but I don't see any chance).

Thanks for helping,

Bernhard
--
Sent through Global Message Exchange - http://www.gmx.net
Steffen Weinreich
2000-06-02 16:18:51 UTC
Permalink
Post by b***@gmx.net
I am connected via TCP/IP connection to the CMG SMSC (UCP). I have traced
the data in the pakets which are sent to the SMSC. UCP51 is used to send the
paket. The problem is that this doesn't work with the SMSC. I have tested
with another software and it is using UCP01 and it works perfectly.
Is it possible to send with UCP01 instead of using UCP51 (I know that
UCP01 should be used any longer but I don't see any chance).
Kannel does not support submittion of SMS via OT 01. It is not very
difficult to hack support for this into the code, but it is very limited in
functionality. As soon as you need UDH or other feature, OT 51 is the way
to go.

cheerio
Steve
Lars Wirzenius
2000-06-02 16:56:03 UTC
Permalink
Post by b***@gmx.net
Is it possible to send with UCP01 instead of using UCP51 (I know that
UCP01 should be used any longer but I don't see any chance).
I don't know of a configuration option for that (rpr or dark will
tell otherwise, if I'm wrong). If you need it, you'll have to change
the code. If you do, please send a patch, hopefully so that it can
be made configurable from the configuration file. Thanks.
--
Lars Wirzenius <***@wapit.com>
Architect, Kannel WAP and SMS Gateway project, Wapit Ltd, http://www.kannel.org
Karl Guggisberg
2000-06-02 17:45:06 UTC
Permalink
Post by Steffen Weinreich
Kannel does not support submittion of SMS via OT 01. It is not very
difficult to hack support for this into the code, but it is very limited in
functionality. As soon as you need UDH or other feature, OT 51 is the way
to go.
I'm aware of UCP as defined in GSM 03.39 which is
missing support for UDH. What is UCP51 and where is it defined ?

Thanks in advance !

Karl
Mikael Gueck
2000-06-02 18:02:08 UTC
Permalink
Hi Karl, developers,
Post by Karl Guggisberg
Post by Steffen Weinreich
Kannel does not support submittion of SMS via OT 01. It is not very
difficult to hack support for this into the code, but it is very limited in
functionality. As soon as you need UDH or other feature, OT 51 is the way
to go.
I'm aware of UCP as defined in GSM 03.39 which is
missing support for UDH. What is UCP51 and where is it defined ?
Please see the Clause 5.B of the GSM 03.39 document version
6.0.0 Release 1997. This clause (named "50-Series of EMI
Messages") should contain the information you are looking for.

Cheers,
Mikael Gueck, Project Mangler, Wapit Ltd.
+358-50-3000009 ***@wapit.com
Zouheir LAKHDISSI
2000-06-05 14:58:58 UTC
Permalink
Hi all
i'm sorry to disturb you but i'm urgently needing help
i want to create an application that sends sms to an sms center
can i know what are the files in kennel i should use and what kind of
modifications i should do
Thanx in advance and resorry
LAKHDISSI
WAP/SMS Project

Steffen Weinreich
2000-06-03 09:20:59 UTC
Permalink
Post by Karl Guggisberg
Post by Steffen Weinreich
Kannel does not support submittion of SMS via OT 01. It is not very
difficult to hack support for this into the code, but it is very limited in
functionality. As soon as you need UDH or other feature, OT 51 is the way
to go.
I'm aware of UCP as defined in GSM 03.39 which is
missing support for UDH. What is UCP51 and where is it defined ?
the UCP Operation type (OT) 51 which is defined in 03.39 could also be used to
submit UDH messages. this is not documented in GSM 03.39 only in the CMG Docs
which I am not able to citate or comment. If you need information about this ask
your operator or CMG, or read the kannel source.

cheerio
Steve
Karl Guggisberg
2000-06-02 18:31:05 UTC
Permalink
Post by Mikael Gueck
Please see the Clause 5.B of the GSM 03.39 document version
6.0.0 Release 1997. This clause (named "50-Series of EMI
Messages") should contain the information you are looking for.
I recently had a look at this. In principle, the field
TMsg could consist of an opaque binary SMS, including leading
User Data Headers. However, I did not find a field which sets the
User-Data-Header-Indication Bit. Furthermore, Mannesman
D2 mentiones a field 'XSer' for User Data Headers in its
interface specification. I could not find 'XSer' in GSM 03.39.

Is there any newer version of the UCP protocol around ?

Karl
Mikael Gueck
2000-06-02 19:03:17 UTC
Permalink
Hi Karl,
Post by Karl Guggisberg
Post by Mikael Gueck
Please see the Clause 5.B of the GSM 03.39 document version
6.0.0 Release 1997. This clause (named "50-Series of EMI
Messages") should contain the information you are looking for.
I recently had a look at this. In principle, the field
TMsg could consist of an opaque binary SMS, including leading
User Data Headers. However, I did not find a field which sets the
User-Data-Header-Indication Bit. Furthermore, Mannesman
D2 mentiones a field 'XSer' for User Data Headers in its
interface specification. I could not find 'XSer' in GSM 03.39.
this is a example EMI52 message containing a WDP/WSP frame. Hope
it helps. My email client may decide to insert some newlines
after every 72 characters, unfortunately.

The 'aaabbbcccdddpppp' part is actually a IP address in the form
of 'aaa.bbb.ccc.ddd', port 'pppp', which I can't publish for
security reasons.

00/00260/O/52/aaabbbcccddddpppp/0407735654////////////0000/020600215631////4/0632/06050423F0C34E01400A687474703A2F2F616A748094809580A180988083839F81848102EA5181040203E83DA94E6F6B6961373131
302F312E30202830342E38302900582D5741502E544F44000100///1/1//////0000///AB

Cheers,
Mikael Gueck, W
Steffen Weinreich
2000-06-05 06:24:07 UTC
Permalink
Post by Mikael Gueck
Hi Karl,
Post by Karl Guggisberg
I recently had a look at this. In principle, the field
TMsg could consist of an opaque binary SMS, including leading
User Data Headers. However, I did not find a field which sets the
User-Data-Header-Indication Bit. Furthermore, Mannesman
D2 mentiones a field 'XSer' for User Data Headers in its
interface specification. I could not find 'XSer' in GSM 03.39.
The format of the XSer field is described in the D2 Mannesmann Doc.
on Pg.43-44. Th GSM 03.39 is too old to contain this.
Post by Mikael Gueck
this is a example EMI52 message containing a WDP/WSP frame. Hope
it helps. My email client may decide to insert some newlines
after every 72 characters, unfortunately.
The 'aaabbbcccdddpppp' part is actually a IP address in the form
of 'aaa.bbb.ccc.ddd', port 'pppp', which I can't publish for
security reasons.
00/00260/O/52/aaabbbcccddddpppp/0407735654////////////0000/020600215631////4/0632/06050423F0C34E01400A687474703A2F2F616A748094809580A180988083839F81848102EA5181040203E83DA94E6F6B6961373131
302F312E30202830342E38302900582D5741502E544F44000100///1/1//////0000///AB
Cheers,
Mikael Gueck, W
This message may contain a UDH, but it is not correctly formatted. A
correctly formatted UDH Msg would have the 06050423F0C34E removed from the
TMsg field, and moved as 010706050423F0C34E to the XSer field. 01 stands for
UDH and 07 for the len aof the UDH.

To work correctly, the Network operator has to tweak his CMG and enable the
UDH support on the large account for MT traffic (which is by default disabled).

cheerio
Steve
Mikael Gueck
2000-06-05 06:54:48 UTC
Permalink
Post by Steffen Weinreich
Post by Mikael Gueck
The 'aaabbbcccdddpppp' part is actually a IP address in the form
of 'aaa.bbb.ccc.ddd', port 'pppp', which I can't publish for
security reasons.
This message may contain a UDH, but it is not correctly formatted. A
correctly formatted UDH Msg would have the 06050423F0C34E removed from
the TMsg field, and moved as 010706050423F0C34E to the XSer field. 01
stands for UDH and 07 for the len aof the UDH.
D'oh! Sorry, here's the complete message in the correct format:

00/00260/O/52/aaabbbcccdddpppp/0407735654////////////0000/050600094113////4/0576/01400A687474703A2F2F616A748094809580A180988083839F81848102EA5181040203E83DA94E6F6B6961373131302F312E30202830342E38302900582D5741502E544F44000100///1/1//////010706050423F0C34E///B9
Post by Steffen Weinreich
To work correctly, the Network operator has to tweak his CMG and
enable the UDH support on the large account for MT traffic (which
is by default disabled).
My fault, I accidentally used a large account without the UDHI
to obtain the example message. :/

Thanks for pointing this out.

Cheers,
Mikael
Continue reading on narkive:
Loading...