Subject: Re: [Sigtran] Sigtran Plugtest - DAY 2-5: DAUD Question

From: [email-masked]
Date: Wed, 10 Sep 2003 17:25:01 +0530

Hi all,
       Figure below shows two AS's AS1 with routing key DPC only, AS2 with
routing key (DPC + OPC). One of the questions that was raised in recent
plugtest
     was that if AS1 sends DAUD message for point code a.b.c what should be
the response of SG to the received DAUD from AS. Some of the
     particepants said DUNA.Please give your comments on the same.

                                             DPC x.y.z

                                           +------------+
                                           |            |
                                       -----            |
                                      |    |   AS 1     |
                                      |    |            |
    PC p.q.r      +-----------+       |    +------------+
   +------+       |           |       |
   |      |       |           |       |
   |      --------|  SG       --------
   |      |       |           --------     +------------+
   +------+       |           |       |    |            |
                  +-----------+       |    |            |
                                       -----   AS 2     |
                                           |            |
                                           +------------+
                                             DPC a.b.c
                                                +
                                             OPC d.e.f

Regards
Kamesh Kaul
www.hssworld.com
Hughes Software Systems

"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."

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

---

From: "Narendar Goel" <[email-masked]>
Date: Wed, 10 Sep 2003 17:50:04 -0400

I think it should be DAVA/DUNA depending on state of AS2. When AS2
comes up probably SG will propogate a MTP-RESUME for point code
a.b.c on SS7 network to enable SS7 entities to send messages to 
a.b.c.
 Thanks,
Narender

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Wednesday, September 10, 2003 7:55 AM
To: [email-masked]
Cc: Ken Morneault
Subject: Re: [Sigtran] Sigtran Plugtest - DAY 2-5: DAUD Question

Hi all,

                                             DPC x.y.z

                                           +------------+
                                           |            |
                                       -----            |
                                      |    |   AS 1     |
                                      |    |            |

Regards
Kamesh Kaul
www.hssworld.com
Hughes Software Systems

---

From: "Vivek Toky" <[email-masked]>
Date: Thu, 11 Sep 2003 12:18:32 -0700

Hi All,
  I think DAUD and other SSNM messages are intended to be used for the
destinations which are on SS7 network. SG is intelligent enough to
distinguish whether a point code is in SS7 domain or in IP domain. As you
can see in RFC section 3.4.1

  "The DUNA message is sent from an SGP in an SG to all concerned ASPs to
indicate that the SG has determined that one or more SS7 destinations are
unreachable.  It is also sent by an SGP in response  to a message from the
ASP to an unreachable SS7 destination."

   What does the term "SS7" in the above paragraph indicates?

  Also, I don't see any reason why ASP should route the messages for another
ASP through a gateway. IMO, SGP should not allow ASPs to send data to other
ASPs Via SGP, otherwise ASPs may keep hogging SGPs, when they don't really
need an SGP. ASPs can work in IPSP modes for inter-ASP  data exchanges and
No SSNM messages are required.

regards,
Vivek.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Narendar Goel
Sent: Wednesday, September 10, 2003 2:50 PM
To: [email-masked]; [email-masked]
Cc: Ken Morneault
Subject: RE: [Sigtran] Sigtran Plugtest - DAY 2-5: DAUD Question

-----Original Message-----

Hi all,

                                             DPC x.y.z

                                           +------------+
                                           |            |
                                       -----            |
                                      |    |   AS 1     |
                                      |    |            |

Regards
Kamesh Kaul
www.hssworld.com
Hughes Software Systems

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 11 Sep 2003 15:23:25 -0400

Hi Vivek,
> Vivek Toky
> Sent: Thursday, September 11, 2003 3:19 PM
> To: Narendar Goel; [email-masked]; [email-masked]
> Cc: Ken Morneault
[TOLGA]It indicates a SS7 destination, which might reside in IP or in TDM
domain.
> No SSNM messages are required.
[TOLGA]It was agreed to support this mode of operation, and in general
personally I don't see any harm on this. Some SGs might support it and some
of them might not. And I believe if IPSP mode is supported on AS side, not
going through a SG is just a matter of configuration.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 11 Sep 2003 13:25:43 -0600

Vivek,

There is no need to distiguish between this:

A)

      PC A                      PC B
    _________                 _________ 
   |         |               |         |
   |   ASP   |               |   ASP   |
   |_________|               |_________|
        |                         |
        |___________   ___________|
                    | |
                 ___|_|___
                |         |
                |   SGP   |
                |_________|

And this:

B)

      PC A                      PC B
    _________                 _________ 
   |         |               |         |
   |   ASP   |               |   ASP   |
   |_________|               |_________|
        |                         |
        |                         |
        |                         |
        |                         |
    ____|____                 ____|____
   |         |     SS7       |         |
   |   SGP   |--- Network ---|   SGP   |
   |_________|               |_________|

Anything with a point code is a destination in the SS7 network.
That includes AS.

An operator may wish to block the first from a purely administrative or
security point of view, but this is already provided in the RFC:

   The "Destination Status Unknown" Error MAY be sent if a DAUD is
   received at an SG enquiring of the availability/congestion status of
   a destination, and the SG does not wish to provide the status (e.g.,
   the sender is not authorized to know the status).  For this error,
   the invalid or unauthorized Point Code(s) MUST be included along with
   the Network Appearance and/or Routing Context associated with the
   Point Code(s).

The foregoing passage also addresses Gateway Screening.

But that is something completely asside from configuration and applies
to any destination in any configuration.

There is no reason to send DUNA just because the configuration is that
of A) above.  If the SG permits transfer to the audited destination from
the auditting AS, it should respond as for any other SS7 destination.
If it does not permit transfer, the error above may be used.

--brian

Vivek Toky wrote:                                                                    (Thu, 11 Sep 2003 12:18:32)

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

---

From: "Vivek Toky" <[email-masked]>
Date: Thu, 11 Sep 2003 14:28:36 -0700

Hi Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Tolga Asveren
Sent: Thursday, September 11, 2003 12:23 PM
To: [email-masked]
Subject: RE: [Sigtran] Sigtran Plugtest - DAY 2-5: DAUD Question

Hi Vivek,

[Vivek] Then why to use term SS7 ? Why not use term "Point Code". If SSNM
procedures are applicable to all point codes then this term "SS7" should be
removed and also procedures should be defined such that if AS inactivates
itself and that AS represents a point code then a DUNA should be sent to all
the active/inactive ASPs.

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 11 Sep 2003 17:56:10 -0400

Hi Vivek,
> Sent: Thursday, September 11, 2003 5:29 PM
> To: Tolga Asveren; [email-masked]
[TOLGA]But AS is also a SS7 destination. And furthermore, if you think that
we should define the procedures you mentioned, then why don't you think we
should define them for the case where the traffic flow is between ASP in IP
domain and a SEP in TDM domain? There is no difference IMO, and I think
there is also no need to define those procedures. In fact enough explanation
is already there, for example "The DUNA message is sent from an SGP in an SG
to all concerned ASPs to indicate that the SG has determined that one or
more SS7 destinations are unreachable."

---

From: "Vivek Toky" <[email-masked]>
Date: Thu, 11 Sep 2003 18:17:05 -0700

Brian,

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, September 11, 2003 12:26 PM
To: Vivek Toky
Cc: Narendar Goel; [email-masked]; [email-masked]; Ken Morneault
Subject: Re: [Sigtran] Sigtran Plugtest - DAY 2-5: DAUD Question

Vivek,

A)

      PC A                      PC B
    _________                 _________
   |         |               |         |
   |   ASP   |               |   ASP   |
   |_________|               |_________|
        |                         |

And this:

B)

      PC A                      PC B
    _________                 _________
   |         |               |         |
   |   ASP   |               |   ASP   |
   |_________|               |_________|
        |                         |
        |                         |
        |                         |
        |                         |
    ____|____                 ____|____
   |         |     SS7       |         |

[Vivek] IMO, for M3UA anything with a point code and which can be accessible
only through SG is an SS7 destination (which may be an AS). If you refer
back to RFC then you find SS7 destination terms have been used only in
context of SGP. If your statement holds true then one IPSP may be accessible
via other IPSP. Why SSNM messages have not been defined for IPSPs ?

      PC A                          PC B
    __________                  __________
   |          |                |          |
   |  IPSP    |                |  IPSP    |
   |__________|                |__________|
        |                           |
        |____________   ____________|
                     | |
                  ___|_|____
                 |          |
                 |  IPSP    |
                 |__________|
                     PC C

--brian

Vivek Toky wrote:
(Thu, 11 Sep 2003 12:18:32)

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

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 11 Sep 2003 20:25:10 -0700 (PDT)

Hi Vivek,
> There is no need to distiguish between this:
[TOLGA]The reason for that is because they are
directly communicating with each other. There is no
relaying support for IPSP mode of operation -so there
are no PCs, which you can access indirectly via
another IPSP and for which you would receive SSNM-
> >   Also, I don't see any reason why ASP should
> route the messages for
> another
> > ASP through a gateway. IMO, SGP should not allow
> ASPs to send data to
> other
> > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > Narendar Goel
> > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > [email-masked]
> >      was that if AS1 sends DAUD message for point
> code 
=== message truncated ===

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 11 Sep 2003 22:27:11 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 11 Sep 2003 20:25:10)
> another IPSP and for which you would receive SSNM-

Tolga is correct.  (We had this discussion a number of times.)  By definition,
PC B is inaccessible from PC A because IPSP with PC C cannot relay.  Only SGPs
relay.

The other difference here is that in A) and B) above, there is no PC C.  PC A
and PC B actually belong to the SGP to which they are associated.  The AS is
not a point code.  The AS is an MTP-User (not an MTP-Provider).  Point codes
are used to name MTP3 stacks, not MTP users.  MTP users are identifiable
within the SS7 network as an MTP-SAP (PC/SI tuple).  So, although we label
PC A and PC B against the ASP, it is really only identifies the MTP stack at
the SGP.

So, for example, AS1 providing an ISUP MTP-User at PC B/SI=5 can be
unavailable, and the MTP3 for PC B is still accessible at the SGP.  That is
why I say that in configuration A) above, the proper response is DAVA.
Because PC A and PC B MTP are provided by the same SGP, they are either
both accessible or both inaccessible.  It does not depend on the state of
the AS.

Do you understand?

--brian

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

---

From: "Umesh Vats" <[email-masked]>
Date: Fri, 12 Sep 2003 08:59:29 -0700

>From the discussion it looks like that in the diagram below,
user parts on ASP A and ASP B can exchange data via SGP.

                  |------------- ASP A(DPC X)
            SGP---|
                  |------------- ASP B (DPC Y)

If this is the case, then the text in RFC is not sufficiently conveying the
intended behaviour. I am quoting some of the references below :

---------------------------------------------------------------
1.4.2.4 Message Distribution at the SGP

   To direct messages received from the SS7 MTP3 network to the
   appropriate IP destination, the SGP must perform a message
   distribution function using information from the received MTP3-User
   message.

Umesh : Here, no mention is made of how SGP should distribute messages
   received from SS7 IP network.
-----------------------------------------------------------------
1.4.6 Congestion Management

   When an SG determines that the transport of SS7 messages to a
   Signalling Point Management Cluster (SPMC) is encountering
   congestion, the SG MAY trigger SS7 MTP3 Transfer Controlled
   management messages to originating SS7 nodes, per the congestion
   procedures of the relevant MTP3 standard.

Umesh : Here, no mention is made of trigerring SCON messages to
   other ASP serving AS belonging to different point codes.
------------------------------------------------------------------
3.4.4 Signalling Congestion (SCON)

   The SCON message can be sent from an SGP to all concerned ASPs to
   indicate that an SG has determined that there is congestion in the
   SS7 network to one or more destinations, or to an ASP in response to
   a DATA or DAUD message as appropriate.  For some MTP protocol
   variants (e.g., ANSI MTP) the SCON message may be sent when the SS7
   congestion level changes.  The SCON message MAY also be sent from the
   M3UA layer of an ASP to an M3UA peer indicating that the M3UA layer
   or the ASP is congested.

UMESH : Here, SS7 network is mentioned specifically but IP network is not
mentioned.
----------------------------------------------------------------------
3.4.5 Destination User Part Unavailable (DUPU)

   The DUPU message is used by an SGP to inform concerned ASPs that a
   remote peer MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is
   unavailable.

Umesh : here, does SS7 node means node in SS7 network or it means SS7
   point code. Same  name should be used consistently.
----------------------------------------------------------------------
4.1.1 Receipt of Primitives from the M3UA-User

   On receiving an MTP-TRANSFER request primitive from an upper layer at
   an ASP/IPSP, or the nodal interworking function at an SGP, the M3UA
   layer sends a corresponding DATA message (see Section 3) to its M3UA
   peer.  The M3UA peer receiving the DATA message sends an MTP-TRANSFER
   indication primitive to the upper layer.

Umesh : Here, it is mentioned that M3UA peer receiving the DATA message
sends MTP-TRANSFER indication to upper layer. But in the diagarm above, SGP
may send data request to SCTP. This is missing.
-------------------------------------------------------------------------

There is no diagram in the RFC which mentions the intended behaviour.
Atleast one diagram should be present depicting this behaviour clearly.

Regards
Umesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Thursday, September 11, 2003 9:27 PM
To: Tolga Asveren
Cc: [email-masked]
Subject: Re: [Sigtran] Sigtran Plugtest - DAY 2-5: DAUD Question

Tolga,

Tolga Asveren wrote:
(Thu, 11 Sep 2003 20:25:10)
> another IPSP and for which you would receive SSNM-

Tolga is correct.  (We had this discussion a number of times.)  By
definition,
PC B is inaccessible from PC A because IPSP with PC C cannot relay.  Only
SGPs
relay.

The other difference here is that in A) and B) above, there is no PC C.  PC
A

Do you understand?

--brian

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

---

From: "Vivek Toky" <[email-masked]>
Date: Fri, 12 Sep 2003 11:24:07 -0700

Brian,

-----Original Message-----

Tolga,

Tolga Asveren wrote:

[Vivek] Do you mean to say that M3UA stack (ASP/AS) is not SS7 destination ?

M3UA stack is only a remotely located SG user ? M3UA/SCTP Stack does not
represent a point code? Then why is the term SPMC required as if SG is
available then everything is available ? In RFC section 1.4.3.1  why is it
written that SG can act as STP or SEP ?

Do you understand?

--brian

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

---

From: "Vivek Toky" <[email-masked]>
Date: Fri, 12 Sep 2003 11:25:00 -0700

I am quoting the definition of SPMC below as given in RFC.

   Signalling Point Management Cluster (SPMC) - The complete set of
   Application Servers represented to the SS7 network under a single MTP
   entity (Signalling Point) in one specific Network Appearance.  SPMCs
   are used to aggregate the availability, congestion, and user part
   status of an MTP entity (Signalling Point) that is distributed in the
   IP domain, for the purpose of supporting MTP3 management procedures
   towards the SS7 network.

   [vivek] Why is it not written that MTP3 management procedures should also
be supported towards IP network
                          In some cases, the SG itself may also be a
   member of the SPMC.  In this case, the SG availability /congestion
   /User_Part status should also be taken into account when considering
   any supporting MTP3 management actions.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Umesh Vats
Sent: Friday, September 12, 2003 8:59 AM
To: [email-masked]; Tolga Asveren
Cc: [email-masked]
Subject: RE: [Sigtran] Sigtran Plugtest - DAY 2-5: DAUD Question

Regards
Umesh

-----Original Message-----

Tolga,

Tolga Asveren wrote:

Do you understand?

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 12 Sep 2003 16:43:20 -0400

Hi Umesh/Vivek,

First I have to say not all of the relevant parts are updated in RFC/IG to
reflect SGs relating capability between AS.
Now consider the folowing configuration:

   AS1:DPC=1-1-1  AS2: DPC=2-2-2
      +------+   +------+
      |      |   |      |
      | ASP1 |   |ASP2  |
      +-----++   ++-----+
            |     |
            |     |
            |     |
            |     |
            |     |
            +-----++
            | SGP1 |
            |      |3-3-3
            +------+

And when I enhance the diagram with the location of MTP3 logics for
different PCs:

   AS1:DPC=1-1-1      AS2: DPC=2-2-2
    +------+            +------+
    |      |            |      |
    | ASP1 |            |ASP2  |
    +---+--+            +---+--+
        |                   |
        |                   |
        |                   |
        |                   |
        |                   |
        |                   |
        |                   |
        |                   |
     +--+-------------------+------+
     |                             +
     |                             |
     |+--------+       +--------+  |
     || MTP3   |       | MTP3   |  |
     || 1-1-1  |       | 2-2-2  |  |
     |+--------+       +--------+  |
     |                             |
     |        +--------+           |
     |        | MTP3   |           |
     |        | 3-3-3  |           |
     |        +--------+   SGP1    |3-3-3
     +-----------------------------+
Please note that MTP3 boxes in the diagram do not represent full MTP3 logic,
but just relevant MTP3 procedures(for 3-3-3 of course we have the full MTP3)
I didn't draw the logical connections between MTP3 entities, because it is
very much implementation dependent, might be a direct or indirect logical
connection .So, in fact inside the SG -which is working in STP mode-, there
is already a small MTP3 network present (probably by considering this, there
aren't too many updates necessary in the documents)

Based on that, one might argue, even if the AS is not ACTIVE, still there
shouldn't be a TFP sent for the corresponding PC-because MTP3 is reachable,
but depending on implementation even that MTP3 entity might be unreachable
from MTP3(3-3-3) -if somehow inactivity of AS causes the direct/indirect
logical connection between them to break-.

   Tolga
> Sent: Friday, September 12, 2003 2:25 PM
> To: [email-masked]; [email-masked]; Tolga Asveren
> Cc: [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 12 Sep 2003 15:23:37 -0600

Vivek,

Vivek Toky wrote:                                                                    (Fri, 12 Sep 2003 11:24:07)
> written that SG can act as STP or SEP ?

SPMC is at the SG.  SPMC is the state of the point code.  The point code
lives at the SG.  The AS just uses it.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 12 Sep 2003 15:26:57 -0600

Vivek,

Vivek Toky wrote:                                                                    (Fri, 12 Sep 2003 11:25:00)
>    any supporting MTP3 management actions.

'Cause the SG controls the state of the SPMC.  The SPMC is just an abstraction
used to talk about the management state of a point code towards the SS7
network.  This is performed by the SG and, more importantly by the SG MTP3
stack.  It is not performed by the ASP.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 12 Sep 2003 15:29:48 -0600

Umesh,

Even so, it was agreed.

Also, this *is* the SE IPSP scenario.  So, perhaps the statements about IPSP
are more applicable.

--brian

Umesh Vats wrote:                                                                    (Fri, 12 Sep 2003 08:59:29)

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

---

From: "Umesh Vats" <[email-masked]>
Date: Fri, 12 Sep 2003 14:48:06 -0700

If it was agreed by all, thats fine. But as long as the agreed behaviour is
not consistently captured in RFC or implementor's guide, it will pose
interoperabilty problems as discovered during the recent bakeoff for M3UA.

I think, this behaviour should be captured in the implementor's guide. All
the sections in RFC should be made consistent with this behaviour.

regards
Umesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Friday, September 12, 2003 2:30 PM
To: Umesh Vats
Cc: Tolga Asveren; [email-masked]
Subject: Re: [Sigtran] Sigtran Plugtest - DAY 2-5: DAUD Question

Umesh,

Even so, it was agreed.

--brian

Umesh Vats wrote:
(Fri, 12 Sep 2003 08:59:29)

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

---

From: "Vivek Toky" <[email-masked]>
Date: Fri, 12 Sep 2003 15:25:34 -0700

Hi Brian/Tolga,

	What is the final answer to the following question

1. If some AS is inactive and other AS tries to send data to Inactive AS
through SG, then what should SG do ?

  a) Send DUNA ? (which is not possible as Destination is always available)

  b) Send DUPU ? (which user should be used if routing key towards AS is DPC
only)

  c) Discard Data ? (But then AS will keep on sending more data without
knowing that its being discarded)

  d) Send Error ? (Error will not directly issue pause/user unavailable
indication to the user but will tell the operator that there is something
wrong)

thanks,
Vivek.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Friday, September 12, 2003 2:27 PM
To: Vivek Toky
Cc: [email-masked]; Tolga Asveren; [email-masked]
Subject: Re: [Sigtran] Sigtran Plugtest - DAY 2-5: DAUD Question

Vivek,

Vivek Toky wrote:
(Fri, 12 Sep 2003 11:25:00)
>    any supporting MTP3 management actions.

'Cause the SG controls the state of the SPMC.  The SPMC is just an
abstraction
used to talk about the management state of a point code towards the SS7
network.  This is performed by the SG and, more importantly by the SG MTP3
stack.  It is not performed by the ASP.

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 12 Sep 2003 18:38:10 -0400

Vivek,
> Sent: Friday, September 12, 2003 6:26 PM
> To: [email-masked]
[TOLGA]No, this is possible. Depending on your implementation MTP3
corresponding to your AS might really be inaccessible and even not still you
might choose to send it. What you do inside your SG is implementation
dependent. You might model so that inactivity of AS causes the logical
relationship between MTP3 logics to break or not. From operation point of
view, sending DUNA when the AS is not available (still considering the case
where RK is DPC), sounds more friendly to me.
But what I don't understand is, why people consider this -replying with DUNA
or with DUPU or even with nothing) as "interoperability problem".
>   b) Send DUPU ? (which user should be used if routing key
[TOLGA]You can also try to send DUPU, you know the user part, for which the
message is sent.
> knowing that its being discarded)
[TOLGA]This sure you will do and I would recommend also one of the above.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 12 Sep 2003 17:34:55 -0600

Umesh,

Can you propose text for the IG?

--brian

Umesh Vats wrote:                                                                    (Fri, 12 Sep 2003 14:48:06)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 12 Sep 2003 17:39:27 -0600

Vivek,

The SG should respond in accordance with the state of the SPMC as viewed
by the SG, and considering any security or gateway screening routing policies
present in the MTP3 portion of the SG.

That is, the SG should treat the message the same as any other message
arriving to be distributed to the AS.  If it would send UPU to the SS7
network, it sends DUPU to the originating AS.  If it would sent TFP to the
SS7 newtork, it sends DUNA to the originating AS.  If it would sent TFR
to the SS7 newtork, it sends DRST to the originating AS.  If it would simply
process the message on the default AS or to another ASP, it processes the
message.

Understand?

This is implicit in the RFC.

--brian

Vivek Toky wrote:                                    (Fri, 12 Sep 2003 15:25:34)

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