The SMPP protocol really is a tunnelling protocol - one set of
endpoints is subscriber-to-subscriber, the other is server-to-server,
in this case, SMSC-to-ESME.
Since the subscriber-to-subscriber endpoints can use IP endpoint
addressing, ISDN endpoint addressing, or a mixture of IP and ISDN
addressing, it sounds like you really want to tunnel, but your inner
addressing is just strange.
Can you tell us any more about what you're trying to do?
Spencer
----- Original Message -----
From: "Haim Rochberger" <haimro(_at_)p-cube(_dot_)com>
To: <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>; "Haim Rochberger"
<haimro(_at_)p-cube(_dot_)com>
Cc: <ietf(_at_)ietf(_dot_)org>
Sent: Sunday, January 25, 2004 11:20 AM
Subject: RE: packets of multiple users sent over the same TCP/IP
session
Hi Valdis,
Thanks for the reply.
SMPP is a good example to what I am looking for, and I am trying to
see if
other
protocol foreseen in the future (or past) have the same
characteristics:
The special thing about SMPP is that in the same TCP/IP session
packet that
are really SMS embedded in IP
are sent from one network element (called SMSC) to another (called
ESME) -
so that the packets (i.e. SMS) belong to different mobile users.
In this case I cannot map the IP address of the TCP session to one
specific
mobile subscriber - and the only way I can
identify the subscriber is by "looking" on the SMPP layer (above the
TCP)
and extract the subscriber mobile number.
Another example may be SMTP (not sure).
Anyway the thing I am trying to solve is whether I should consider
this kind
of protocol characteristic as "special" and "rare", and so build a
dedicated
solution for SMPP, or maybe I can expect to see many more such
protocol and
so I should build a more generic solution.
It is obvious to me that a generic solution is better technically,
but since
my resources (i.e. time) is limited,
I need to see how rare this kind of protocol (same TCP/IP with
packets of
multiple users) is common/expected.
Another characteristic of SMPP that I am looking for its
"commonness" is the
fact that there could be many
TCP/IP session from many SCSCs to ESMEs at the same time - and
packets of
the SAME subscriber may appear
on them at the same time...
Complicated :-) that's my life (-:
yours,
Haim Rochberger
-----Original Message-----
From: Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu
[mailto:Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu]
Sent: Sun, January 25, 2004 6:43 PM
To: Haim Rochberger
Cc: 'ietf(_at_)ietf(_dot_)org'
Subject: Re: packets of multiple users sent over the same
TCP/IP session
On Sun, 25 Jan 2004 15:42:28 +0200, Haim Rochberger
<haimro(_at_)p-cube(_dot_)com> said:
I will appreciate your help as it will help in making a
better design
decisions.
Hmm.. been a while since I've had to post this. ;)
The first thing you want to do is take a step *back* from the
problem, and ask
yourself what problem you're trying to solve via this
multiplexing. You
already said you didn't want to use tunneling, but at the
same time you gave us
insufficient information to know if SMPP or anything similar
is applicable to
your problem. With the information you gave, it's likely many
will fear to give
you any really useful answers for fear of sending you in a
totally useless
direction.
For all I know, HTTP pipelining may be a solution to your
problem - in that
scenario, you have in-flight packets for multiple HTTP requests
(read
"subscribers") active at the same time. On the other hand,
although it meets
the requirements you stated, it's almost certainly not the
right answer. But
not knowing what problem you're trying to solve, it's hard to say.
Basically, you need to make sure that what you have in your
hand is a nail
rather than a screw *before* you start selecting hammers....
_______________________________________________
This message was passed through
ietf_censored(_at_)carmen(_dot_)ipv6(_dot_)cselt(_dot_)it,
which is a sublist of ietf(_at_)ietf(_dot_)org(_dot_) Not all messages are
passed.
Decisions on what to pass are made solely by IETF_CENSORED ML
Administrator (ietf_admin(_at_)ngnet(_dot_)it).