Ethereal-dev: [Ethereal-dev] Question if Nokia's SMRSE (SMS over IP) dissector is already avai

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Roman Sagl <roman.sagl@xxxxxxxxxx>
Date: Mon, 15 Nov 2004 20:08:27 +0100

Dear Developpers,
 
I checked already all available protocols, but I coulnd not find SMRSE - "SMS over IP". It will be used between MSC and SMSCs from Nokia.
 
 
It would be great if someone youd support me in this case.
 
 
Best Regards
Roman Sagl
 
 
 

7.2.1.2 ASN specification

PDUs are entities which are used in a protocol to communicate with the peer entity.

Some of the PDUs (Alert, Ack, Error) have gone through minor changes, compared to

the definitions in the GSM 03.47. The following list depicts all the PDUs used between

the MSC and SMSC.

1.8-6 CAG63590 en 7 3

Issue Document Chapter Page

Copyright Nokia Networks Oy

SMRP

DEFINITIONS

IMPLICIT TAGS

::=

BEGIN

-- EXPORTS everything

SMR-Bind ::= SEQUENCE {

sc-address SMS-Address,

password Password,

... -- For future compatibility

} --

-- sc-address is the PLMN address of the SC as seen by the MSs.

-- The address must be in the international format.

-- upper bound settings

ub-password-length INTEGER ::= 20

-- Definition of Short Message Service address

IMSI-Address ::= OCTET STRING (SIZE(1..8))

SMS-Address ::= SEQUENCE {

address-type INTEGER {

unknown-type (0),

internat-number (1), -- international

national-number (2),

net-spec-number (3), -- network specific

short-number (4)

} (0..15),

numbering-plan INTEGER {

unknown-numbering (0),

iSDN-numbering (1),

data-network-numbering (3),

telex-numbering (4),

national-numbering (8),

private-numbering (9)

} (0..15),

address-value CHOICE {

octet-format SemiOctetString

-- other formats are for further study

}

}

-- each octet contains two binary coded decimal digits

SemiOctetString ::= OCTET STRING (SIZE (1..10))

Password ::= PrintableString(SIZE(0..ub-password-length))

SMR-Bind-Confirm ::= SEQUENCE {

-- an empty sequence

... -- For future compatibility

} --

1.8-6 CAG63590 en 7 4

Issue Document Chapter Page

Copyright Nokia Networks Oy

SMR-Bind-Failure ::= SEQUENCE {

connect-fail-reason Connect-fail,

... -- For future compatibility

} --

-- connect-failure-reason contains one of the error given in the following

-- table.

--

-- Connection Failure Reason

-- not-entitled: The responder is not entitled to accept a request for an

-- association between itself and the initiator.

-- temporary-overload: The responder is not capable of establishing an

-- association due to temporary overload.

-- temporary-failure: The responder is not capable of establishing an

-- association due to a temporary failure

-- (having impact on an entity at SM-RL or at layers above).

-- incorrect-ID-or-password: The responder will not accept the request to

-- establish an association between itself and the

-- initiator due to incorrect identity or password.

-- not-supported: The responder does not recognize the telecommunication

-- subsystem type of the initiator, or cannot support any

-- of the operations suggested on the association.

-- inv-SC-addr: The specific SC not alloved to establish a connection.

Connect-fail ::= INTEGER {

not-entitled (0),

tmp-overload (1),

tmp-failure (2),

id-or-passwd (3),

not-supported (4),

inv-SC-addr (5)

}

SMR-Unbind ::= SEQUENCE {

-- an empty sequence

... -- For future compatibility

} --

RPDataMT ::= SEQUENCE {

mt-priority-request BOOLEAN,

mt-mms BOOLEAN,

-- more messages to send

mt-message-reference RP-MR,

mt-originating-address SMS-Address,

mt-destination-address SMS-Address,

mt-user-data RP-UD,

mt-origVMSCAddr [1] SMS-Address OPTIONAL,

-- originators VMSC address, Nokia specific

mt-tariffClass [2] SM-TC OPTIONAL,

-- service tariff, Nokia specific

... -- For future compatibility

} --

RPDataMO ::= SEQUENCE {

1.8-6 CAG63590 en 7 5

Issue Document Chapter Page

Copyright Nokia Networks Oy

mo-message-reference RP-MR,

mo-originating-address SMS-Address,

mo-user-data RP-UD,

origVMSCAddr [1] SMS-Address OPTIONAL ,

-- originator’s VMSC address, Nokia specific

moimsi [2] IMSI-Address OPTIONAL,

-- originator’s IMSI, Nokia specific

... -- For future compatibility

} --

RP-MR ::= INTEGER (0..65535)

RP-UD ::= OCTET STRING (SIZE (1..164))

SM-TC ::= INTEGER (0..65535)

RPAck ::= SEQUENCE {

message-reference RP-MR,

... -- For future compatibility

} --

Error-reason ::= INTEGER {

unknown-subscriber (1),

illegal-subscriber (9),

teleservice-not-provisioned (11),

call-barred (13),

cug-reject (15),

sMS-ll-capabilities-not-prov (19),

error-in-MS (20),

facility-not-supported (21),

memory-capacity-exceeded (22),

absent-subscriber (29),

ms-busy-for-MT-sms (30),

system-failure (36),

illegal-equipment (44),

no-resp-to-paging (60),

gMSC-congestion (61),

dublicate-sm (70),

sC-congestion (101),

mS-not-SC-Subscriber (103),

invalid-sme-address (104)

}

RPError ::= SEQUENCE {

error-reason Error-reason,

msg-waiting-set BOOLEAN,

message-reference RP-MR,

alerting-MS-ISDN [1] SMS-Address OPTIONAL,

sm-diag-info [2] RP-UD OPTIONAL,

... -- For future compatibility

} --

RPAlertSC ::= SEQUENCE {

ms-address SMS-Address,

message-reference RP-MR,

-- Nokia specific

1.8-6 CAG63590 en 7 6

Issue Document Chapter Page

Copyright Nokia Networks Oy

... -- For future compatibility

} --

-- The ms-address must be an international ISDN address. Alerts are acknowledged

-- in this implementation, and therefore, the message-reference parameter is

-- added. Now, RPAlertSC is a sequence instead of the SMS-Address type.

END

7.2.1.3 Data encoding

The encoding of the data remains also the same as before. The protocol data units are

encoded by using the ASN.1/BER encoding. The integrity of the encoding is important,

because the BER encoding/decoding functions are widely used, and therefore, very well

tested, too.

7.2.1.4 Transport frame

The underlying TCP is a stream oriented transport protocol. Short messages are

individual data packages which are to be transferred by using the TCP stream. The

problem is to identify each message from the stream. There is a need for a transport

frame. The frame separates the messages in the stream and makes the identification

possible. So, each PDU is encapsulated into the transport frame which can be seen in the

following picture.

Reserved Length Message Tag Message

126 4..65535 1..12

(1 byte) MSB (2 bytes) LSB (1 byte) (octet string)

Figure 3. Transport frame