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@xxxxxxxxxx> To: <Valdis.Kletnieks@xxxxxx>; "Haim Rochberger" <haimro@xxxxxxxxxx> Cc: <ietf@xxxxxxxx> 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.Kletnieks@xxxxxx [mailto:Valdis.Kletnieks@xxxxxx] > > Sent: Sun, January 25, 2004 6:43 PM > > To: Haim Rochberger > > Cc: 'ietf@xxxxxxxx' > > 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx, which is a sublist of ietf@xxxxxxxxx Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator (ietf_admin@xxxxxxxx).