Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA

From: [email-masked]
Date: Mon, 19 Dec 2005 16:25:13 +0200

Tolga,

>The question is -at least as far as I understand-, whether an 
>SUA-IPSP supports relaying.

Is the question:

1) MAY an IPSP support relaying.
2) SHOULD an IPSP support relaying.
3) MUST an IPSP support relaying.

Which one is the question.

I'd say my answer would be:

1) Yes.
2) Maybe.
3) No.

John

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Ilie Glib <[email-masked]>
Date: Mon, 19 Dec 2005 15:36:06 +0100

Hello John,

I would rather ask

1) MAY an IPSP support interworking with relaying node.
2) SHOULD an IPSP support interworking with relaying node.
3) MUST an IPSP support relaying interworking with relaying node.

By interworking with a relaying node I mean "support receiving of
DUNA, DAVA, etc."

My answer is:

1) Yes.
2) Yes.
3) Yes.

Which is not very obvious from the RFC.

Ilie

---

From: Stanislav Ivanovich <[email-masked]>
Date: Mon, 19 Dec 2005 08:37:16 -0800 (PST)

John, Brian
   
  I think that at this point it is rather clear that SUA paper suffers from the serious children's diseases. All the comments I have read today confirm my original impression that SUA RFC added SCCP alike relay (i.e. GT relay) in an ad-hoc manner.
   
  The major objection is that it uses AS/RC and Signaling Process concepts as used/defined in the M3UA RFC (by making copy/paste from M3UA RFC) and at the same time we hear statements like these:
   
  -----------------------------------------------------------------------------------------
  [JOHN]
  Process-types, in my view, are illustrative text, to give an implementor an idea of what we are talking about - however, they are not meant that each capability MUST be implemented as a separate process.
  -----------------------------------------------------------------------------------------
  [JOHN]
  The notion of a process, IMO, is an implementation issue - different OSes may behave
different.
  -----------------------------------------------------------------------------------------
  [BRIAN]
  It might help you to start with the understanding that, although common text was shared to save redundant wordsmithing, the AS concept for SUA is different from that for M3UA.  Just as it is different for M2UA and IUA, etc.
-----------------------------------------------------------------------------------------
   
  All the statements above do not make sense especially the second one. Of course that no one expects the defintion of a process in an operating system language but instead in the terms of:
   
  1) functionality they perform (e.g. do they contain application functionality or not)
  2) communication protocol the entities/processes use to communicate with each other
   
  As I said in a mail sent on Friday last week:
   
  "A protocol designer must not make any assumptions on the implementation or installation of different protocol entities!
In another words protocol design must only consider communication between logical entities and must not show any dependency on the installation!
Thus in SUA case you achieve SCCP relay at SCCP endpoint by installing two protocol entities at the same place (i.e. in the same machine), namely IPSP (or ASP) and SRP (or SGP).
However nature of the relation between the processes is still clear and kept intact!
Namely IPSP is application and SRP (or SGP whatever you call it) is a process which performs SCCP relay."

  Practically speaking, in my view you have two alternatives for SUA:
   
  1) Abandon or change the original AS/RC/signaling process xxUA concepts (which are strictly followed by M3UA).
  In this case serious rework on the SUA paper is needed since the paper uses (more or less) copy/paste of the fundamental procedures from M3UA.
   
  2) Follow the fundamental/original AS/RC/signaling process principles (which are copy/pasted from M3UA) but cover the relay functionality by introducing another relationship since as said above the AS/RC concept does not originally cover the relay. In this case you need to extend the role of SGP process to relay between IP-IP and introduce SGP-SGP relationship.
   
  I prefer the second option since the AS/RC concept has been originally designed/tailored for direct communication. If one wants to think of any relay in xxUA networks he/she fill very soon realize the complete unsuitability of the AS/RC concept for the building of relay equipped networks. This is especially the case if one wants to do that by following mandatory SE model. In other words there are serious reasons for not allowing the AS/RC concepts be visible/used on the interface between two relay points.
   
  However regardless of this fact the RC (as a pointer to an application served by an application process) does not have any meaning between the processes (whatever you call them) which perform the relay on the SCCP level.
   
  On the other hand the RC has very important and meaningful role on the SGP-ASP and IPSP-IPSP interfaces.
   
  thanks and regards/ Stanislav Ivanovich

[email-masked] wrote:
  Tolga,

Is the question:

1) Yes.
2) Maybe.
3) No.

John

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: "Barry Nagelberg" <[email-masked]>
Date: Mon, 19 Dec 2005 11:54:36 -0500

Stanislav,

Your option #1 below is unnecessary - Brian's statement that the "AS concept for SUA is different from that for M3UA" is
nonsense.

The AS concept is identical in all xUA specs. There may be minor differences in areas such as how the AS is configured,
but the concept is identical.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Stanislav Ivanovich
Sent: Monday, December 19, 2005 11:37 AM
To: SIGTRAN
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA

John, Brian

I think that at this point it is rather clear that SUA paper suffers from the serious children's diseases. All the
comments I have read today confirm my original impression that SUA RFC added SCCP alike relay (i.e. GT relay) in an
ad-hoc manner.

The major objection is that it uses AS/RC and Signaling Process concepts as used/defined in the M3UA RFC (by making
copy/paste from M3UA RFC) and at the same time we hear statements like these:

-----------------------------------------------------------------------------------------
[JOHN]
Process-types, in my view, are illustrative text, to give an implementor an idea of what we are talking about - however,
they are not meant that each capability MUST be implemented as a separate process.
-----------------------------------------------------------------------------------------
[JOHN]
The notion of a process, IMO, is an implementation issue - different OSes may behave
different.
-----------------------------------------------------------------------------------------
[BRIAN]
It might help you to start with the understanding that, although common text was shared to save redundant wordsmithing,
the AS concept for SUA is different from that for M3UA.  Just as it is different for M2UA and IUA, etc.
-----------------------------------------------------------------------------------------

All the statements above do not make sense especially the second one. Of course that no one expects the defintion of a
process in an operating system language but instead in the terms of:

1) functionality they perform (e.g. do they contain application functionality or not)
2) communication protocol the entities/pr! ocesses use to communicate with each other

"A protocol designer must not make any assumptions on the implementation or installation of different protocol entities!
In another words protocol design must only consider communication between logical entities and must not show any
dependency on the installation!
Thus in SUA case you achieve SCCP relay at SCCP endpoint by installing two protocol entities at the same place (i.e. in
the same machine), namely IPSP (or ASP) and SRP (or SGP).
However nature of the relation between the processes is still clear and kept intact!
Namely IPSP is application and SRP (or SGP whatever you call it) is a process which performs SCCP relay."

1) Abandon or change the original AS/RC/signaling process xxUA c! oncepts (which are strictly followed by M3UA).
In this case serious rework on the SUA paper is needed since the paper uses (more or less) copy/paste of the fundamental
procedures from M3UA.

2) Follow the fundamental/original AS/RC/signaling process principles (which are copy/pasted from M3UA) but cover the
relay functionality by introducing another relationship since as said above the AS/RC concept does not originally cover
the relay. In this case you need to extend the role of SGP process to relay between IP-IP and introduce SGP-SGP
relationship.

I prefer the second option since the AS/RC concept has been originally designed/tailored for direct communication. If
one wants to think of any relay in xxUA networks he/she fill very soon realize the complete unsuitability of the AS/RC
concept for the building of relay equipped networks. This is especially the case if one wants to do that by following
mandatory SE ! model. In other words there are serious reasons for not allowing the AS/RC concepts be visible/used on
the interface between two relay points.

However regardless of this fact the RC (as a pointer to an application served by an application process) does not have
any meaning between the processes (whatever you call them) which perform the relay on the SCCP level.

Is the question:

1) MAY an IPSP support relaying.
2) SHOULD an IPSP sup! port relaying.
3) MUST an IPSP support relaying.

1) Yes.
2) Maybe.
3) No.

John

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Dec 2005 11:57:42 -0700

Barry,

Well, Barry, the major difference between the two is SUA IPSP
supports relaying and M3UA IPSP does not.

--brian

Barry Nagelberg wrote:                                                               (Mon, 19 Dec 2005 11:54:36)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Stanislav Ivanovich <[email-masked]>
Date: Mon, 19 Dec 2005 11:21:55 -0800 (PST)

Brian,
   
  Consequence of the AS/RC concept as used in M3UA is that IPSP/ASP equipped relay conceptually, practically and theoretically does not make sense and is not possible. If you claim that SUA IPSP does have possibility to relay why then you didn't change the AS/RC concept for SUA instead of making copy/paste from M3UA? (as I proposed in the option 1)
   
  You just made ad-hoc addition by saying "SUA IPSP does perform SCCP relay" but you didn't look wider on this by considering all the consequences of this addition on the AS/RC/Signaling Process concepts... Instead you used these concepts from M3UA.
   
  My opinion is that you do not see why M3UA does not support relay by ASP/IPSP processes. It is not because there is an "administrative" prohibition on this while the AS/RC concepts do support it. This is not the case!
  Instead not support of relay by ASP/IPSP is a consequence of the fundamental properties of the AS/RC/Signaling Process concepts (which you copy from M3UA).
   
  / Stanislav

"Brian F. G. Bidulock" <[email-masked]> wrote:
  Barry,

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Dec 2005 12:30:01 -0700

Stanislav,

Stanislav Ivanovich wrote:                                                       (Mon, 19 Dec 2005 11:21:55)
> 
>    Brian,
> 
> 
> 
>    Consequence  of  the  AS/RC  concept as  used in M3UA is that IPSP/ASP
>    equipped  relay  conceptually,  practically and theoretically does not
>    make  sense  and is not possible. If you claim that SUA IPSP does have
>    possibility  to relay why then you didn't change the AS/RC concept for
>    SUA  instead  of  making  copy/paste  from M3UA? (as I proposed in the
>    option 1)

In fact, much of the common text in M3UA came from SUA.

> 
> 
> 
>    You  just  made  ad-hoc addition by saying "SUA IPSP does perform SCCP
>    relay"  but  you  didn't  look  wider  on  this by considering all the
>    consequences   of   this   addition  on  the  AS/RC/Signaling  Process
>    concepts... Instead you used these concepts from M3UA.

No.  You were obviously not there while it is happening.  I suggest you
review the mail archive over the last 5 years.

> 
>    My  opinion  is that you do not see why M3UA does not support relay by
>    ASP/IPSP  processes.  It  is  not because there is an "administrative"
>    prohibition  on  this  while the AS/RC concepts do support it. This is
>    not the case!
> 
>    Instead  not  support  of  rela! y by ASP/IPSP is a consequence of the
>    fundamental properties  of the AS/RC/Signaling Process concepts (which
>    you copy from M3UA).

Again, much of these concepts, and particularly the RC concept, come from
SUA and was inserted into M3UA.  See the long ladders on the mailing list
archives with regard to RC in DATA and SNMM.

You are now making pretty bold and brash statements that are not supported
by the facts.

SUA is not M3UA, and please don't try to force the concepts that M3UA adopted
poorly from SUA.

--brian

>      >  Your option #1 below is unnecessary - Brian's statement that the
>      "AS concept for SUA is different from that for M3UA" is
>      > nonsense.
>      >
>      >  The AS concept is identical in all xUA specs. There may be minor
>      differences in areas such as how the AS is configured,
>      > From: [email-masked]
>      [mailto:[email-masked]]On Behalf Of Stanislav Ivanovich
>      >  I  think  that  at  this point it is rather clear that SUA paper
>      suffers from the serious children's diseases. All the
>      >  comments  I  have read today confirm my original impression that
>      SUA RFC added SCCP alike relay (i.e. GT relay) in an
>      > ad-hoc manner.
>      >
>      >  The  major objection is that it uses AS/RC and Signaling Process
>      concepts as used/defined in the M3UA RFC (by making
>      >  Process-types,  in  my  view,  are illustrative text, to give an
>      implementor an idea of what we are talking about - however,
>      >  It might help you to start with the understanding that, although
>      common text was shared to save redundant wordsmithing,
>      >  All the statements above do not make sense especially the second
>      one. Of course that no one expects the defintion ! of a
>      >  "A  protocol  designer  must  not  make  any  assumptions on the
>      implementation or installation of different protocol entities!
>      > In another words protocol design must only consider communication
>      between logical entities and must not show any
>      >  Thus  in  SUA  case  you  achieve SCCP relay at SCCP endpoint by
>      installing two protocol entities at the same place (i.e. in
>      > Namely IPSP is application and SRP (or SGP whatever you! call it)
>      is a process which performs SCCP relay."
>      >
>      >
>      > 1) Abandon or change the original AS/RC/signaling process xxUA c!
>      oncepts (which are strictly followed by M3UA).
>      >  In this case serious rework on the SUA paper is needed since the
>      paper uses (more or less) copy/paste of the fundamental
>      > procedures from M3UA.
>      >
>      >   2)  Follow  the  fundamental/original  AS/RC/signaling  process
>      principles (which are copy/pasted from M3UA) but cover the
>      >  relay functionality by introducing another relationship since as
>      said above the AS/RC concept does not originally cover
>      >  the  relay.  In  this  case  you  need to extend the role of SGP
>      process to relay between IP-IP and introduce SGP-SGP
>      > relationship.
>      >
>      >  I  prefer  the  second  option  since the AS/RC concept has been
>      originally designed/tailored for direct communication. If
>      >  one  wants  to thi! nk of any relay in xxUA networks he/she fill
>      very soon realize the complete unsuitability of the AS/RC
>      >  concept  for  the  building  of relay equipped networks. This is
>      especially the case if one wants to do that by following
>      >  mandatory  SE  ! model. In other words there are serious reasons
>      for not allowing the AS/RC concepts be visible/used on
>      >  However  regardless  of  this  fact  the  RC (as a pointer to an
>      application served by an application process) does not have

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Stanislav Ivanovich <[email-masked]>
Date: Mon, 19 Dec 2005 12:20:21 -0800 (PST)

Brian,
   
  It is irrelevant who made copy from which specification (either September 2002 M3UA from October 2004 SUA or vice versa). The only thing that matters is the fact that M3UA and SUA use the same concepts since the AS/RC related state machines, procedures etc... are the same.
   
  The fact is that the concept is not "tailored" for relay between the IPSP'es/ASP'es (especially considering the fact that SE model is mandatory). However regardless of the SE model the fact is that RC'es (application pointers) do not make any sense on the relay_process<->relay_process interface.
   
  For example what is the point of NOTIFY message on the IPSP<->relay_process interface indicating particular application with RC value??? What shoukd it represent?
   
  Why do you think that you must have AS/RC concept used in between two SUA relay processes? What do you think you loose if you introduce the concpet of the SGP<->SGP interface where you do not use AS/RC concept?
   
  Please explain also how can one build a network of relay processes with mandatory SE model where one has to specify both originating and destination SS7 addresses and only these combinations are allowed? This is extremely relay unfriendly!
   
  On the other hand SGP-SGP principle is fully compatible with AS/RC concepts which are of course used somewhere else (only on SGP-ASP and IPSP-IPSP interfaces) and at the same time very relay friendly since the concept uses the same principles as SCCP<->SCCP relay.
   
  / Stanislav

--brian

> 
> 
> 
> / Stanislav
> 
> 
> 
> "Brian F. G. Bidulock" wrote:
> 
> Barry,

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Dec 2005 19:32:56 -0700

Stanislav,

Stanislav Ivanovich wrote:                                                       (Mon, 19 Dec 2005 12:20:21)
> 
>    Brian,
> 
> 
> 
>    It  is  irrelevant  who  made  copy  from  which specification (either
>    September  2002  M3UA  from  October 2004 SUA or vice versa). The only
>    thing that matters is the fact that M3UA and SUA use the same concepts
>    since  the  AS/RC  related  state  machines, procedures etc... are the
>    same.

By listing the RFC dates do you think they are meaningful to this discussion?
M3UA and SUA text were finalized at about the same time.  M3UA slipped through
before security considerations became paramount, which stalled SUA becoming
an RFC for two years (yes, two years).

Similar concepts, but M3UA never adopted the full SUA model: relay being
one of them.

> 
>    The  fact  is that the concept is not "tailored" for relay between the
>    IPSP'es/ASP'es  (especially  considering  the  fact  that  SE model is
>    mandatory).  However regardless of the SE model the fact is that RC'es
>    (application    pointers)    do    not   make   any   sense   on   the
>    relay_process<->relay_process interface.

On the contrary, the concept was "tailored" for relay, for SUA.  RC makes
perfect sense.  SE vs. DE is a matter of the number of messages exchanged.
Perhaps you can present some example where this is not the case?

>    For   example   what   is   the   point   of  NOTIFY  message  on  the
>    IPSP<->relay_process  interface indicating particular application with
>    RC value??? What shoukd it represent?

RC identifies a flow of traffic between SUA entitites.  The point of a NOTIFY
message containing it is to provide notification with regard to the traffic
flow identified by the RC.

>    Why  do you think that you must have AS/RC concept used in between two
>    SUA   relay   processes?  What  do  you  thin!  k  you  loose  if  you
>    introduce the  concpet of the SGP<->SGP interface where you do not use
>    AS/RC concept?

You are never required to assign RC to traffic flows between any SUA entities.
When no RC is assigned, and the association handles only one traffic flow,
it is optional in all messages.  Don't use it if you don't see a use for it.

>    Please  explain  also  how  can one build a network of relay processes
>    with  mandatory SE model where one has to specify both originating and
>    destination  SS7  addresses  and  only these combinations are allowed?
>    This is extremely relay unfriendly!

You don't have to specify destination or originating addresses.  SUA permits
the description of an RK using GT ranges.  When registering with a IPSP relay
node, an IPSP can use the GT ranges that it expects to be served by the relay.
This is no different than SCCP.

>    On  the  other  hand  SGP-SGP principle is fully compatible with AS/RC
>    concepts  which are of course used somewhere else (only on SGP-ASP and
>    IPSP-IPSP  interfaces)  and at the same time very relay friendly since
>    the concept uses the same principles as SCCP<->SCCP relay.

SG-SG for M3UA defines messages missing from M3UA for peer-to-peer operation.
SUA does is missing no messages.  All SCCP protocol messages are represented
by equivalent SUA messages.  This is different than M3UA.  Also SG-SG for M3UA
avoids the use of RC.  This is because MTP provides no management messages for
its users (other than the feeble UPU) and has no user flow control.  SCCP OTOH
has managements messages for users and performs user flow control and congestion.
This is what permits SUA to manage within an RC. SG-SG concept for M3UA reduces
to pointcode-pointcode connnections, not requiring an RC.  SUA does not.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Ilie Glib <[email-masked]>
Date: Tue, 20 Dec 2005 10:06:15 +0100

Hello Brian,

FYI the RC is mandatory parameter in SUA traffic messages.

Ilie

> Stanislav Ivanovich wrote:                                                       (Mon, 19 Dec 2005 12:20:21)
...

--
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Dec 2005 03:37:58 -0700

Ilie,

There is little difference between RC=0 in every message and an
optional Routing Context parameter.

--brian

Ilie Glib wrote:                                                      (Tue, 20 Dec 2005 10:06:15)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Ilie Glib <[email-masked]>
Date: Tue, 20 Dec 2005 14:19:18 +0100

Brian

According to SUA RFC the RC value shall be unique (at least) within a
Signalling Process, thus one RC value per "signalling relation" is
needed. Consequently a Signalling Process shall have as many RCs as
there are remote SUA peers (ASes). So one value is certainly not
enough.

Ilie

--
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Dec 2005 06:30:54 -0700

Ilie,

No, RC assignment is no different than M3UA: it only needs to uniquely
identify a traffic flow within an association.  When there is only one
traffic flow per association, RC can be trivial (i.e. 0).

Nevertheless, the sender of ASP Active need not include RC, ASP Active
Ack has a mandatory RC value which both peers can populate every subsequent
message requiring an RC.

--brian

Ilie Glib wrote:                                                      (Tue, 20 Dec 2005 14:19:18)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Ilie Glib <[email-masked]>
Date: Tue, 20 Dec 2005 14:51:12 +0100

Brian

what you say (RC values must be unique per AS within IPSP - IPSP
relation and SGP-ASP relation) MUST be clarified in both SUA and M3UA
RFCs.

Currently the RFCs do not define exactly the scope of uniqueness of RC values.

In fact they do and for instance SUA RFC says in Chapter 1.2 Terminology

   Routing Context - An Application Server Process may be configured to
   process traffic within more than one Application Server.  In this
   case, the Routing Context parameter is exchanged between the SGP and
   the ASP (or between two ASPs), identifying the relevant Application
   Server.  From the perspective of an SGP/ASP, the Routing Context
   uniquely identifies the range of traffic associated with a particular
   Application Server, which the ASP is configured to receive.  There is
   a 1:1 relationship between a Routing Context value and a Routing Key
   within an AS.  Therefore the Routing Context can be viewed as an
   index into an AS Table containing the AS Routing Keys.

The last sentence is especially interesting and in fact backs my
statement that a Signalling Process shall have as many RCs as there
are remote SUA peers (ASes) it serves.
One could draw a similar conclusion from M3UA definitions.

Ilie

--
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Dec 2005 06:53:32 -0700

Ilie,

It does not say that the SGP cannot have a different AS Table per
association.

--brian

Ilie Glib wrote:                                                      (Tue, 20 Dec 2005 14:51:12)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Ilie Glib <[email-masked]>
Date: Tue, 20 Dec 2005 14:58:07 +0100

Brian,

well, why RFC does not crarify it?

Ilie

--
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Dec 2005 07:02:53 -0700

Ilie,

Because it is largely an operational consideration.  Operational
considerations were removed and placed in a non-normative appendix
(for both documents).

-brian

Ilie Glib wrote:                                                      (Tue, 20 Dec 2005 14:58:07)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Ilie Glib <[email-masked]>
Date: Tue, 20 Dec 2005 15:28:17 +0100

Brian,

to conclude it, and make the conclusion visible and agreed.
There is a 1:1 relationship between a Routing Context value and a
traffic flow, corresponding to a Routing Key, within an association
between two Signalling Processes. The scope of uniqueness for Routing
Context values is limited by  the association between two Signalling
Processes. The RC values may be assigned independently for any two
associations hold by a Signalling Process.

Is this OK with everybody on SIGTRAN list? Does anybody have objections?

Ilie

--
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Dec 2005 07:34:00 -0700

Ilie,

It goes farther than that.  Under M3UA, an AS can be configured against
an association and never be referred to by RC value at all, by either
side, ever.

--brian

Ilie Glib wrote:                                                      (Tue, 20 Dec 2005 15:28:17)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Barry Nagelberg" <[email-masked]>
Date: Tue, 20 Dec 2005 09:43:02 -0500

Ilie,

This is correct.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Ilie Glib
Sent: Tuesday, December 20, 2005 9:28 AM
To: [email-masked]; Ilie Glib; Stanislav Ivanovich; SIGTRAN
Subject: Re: [Sigtran] AS concepts and Relay in SUA and M3UA

Brian,

Ilie

--
Ilie