[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
Hi Brian,
Thanks for your response but I'm still unclear whether when the AS
becomes active M3UA should immediately consider the route to the SG/STP
as available or whether it should wait for a DAVA. I'm also unclear
whether the SG should respond to DAUD concerning the SG/STPs Point Code
or not.
Best Regards
Howard
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:bidulock at openss7.org]
> Sent: 02 September 2008 15:05
> To: Howard May
> Cc: sigtran at ietf.org
> Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
>
> Howard,
>
> I didn't say that an MTP-User at a signalling point receives an
> MTP-PAUSE for its own point code. What I was saying is that an
> MTP-User at a signalling point can always generate an MTP-TRANSFER
> primitive for a given destination regardless of whether it has
> received an MTP-PAUSE for that destination.
My concern is not with the MTP3 User but rather whether M3UA at the ASP
should consider the route to the SG/STP as available.
While an MTP user may generate MTP-TRANSFER primitives after receiving
an MTP-PAUSE I'm not sure that either ISUP or SCCP should.
Section 7From sigtran-bounces at ietf.org Tue Sep 2 07:59:06 2008
Return-Path: <sigtran-bounces at ietf.org>
X-Original-To: sigtran-archive at megatron.ietf.org
Delivered-To: ietfarch-sigtran-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 367053A6A96;
Tue, 2 Sep 2008 07:59:06 -0700 (PDT)
X-Original-To: sigtran at core3.amsl.com
Delivered-To: sigtran at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 0815B3A6A7E
for <sigtran at core3.amsl.com>; Tue, 2 Sep 2008 07:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.834
X-Spam-Level:
X-Spam-Status: No, score=0.834 tagged_above=-999 required=5 tests=[AWL=0.729,
BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,
J_CHICKENPOX_12=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id WN2Ao5fUltur for <sigtran at core3.amsl.com>;
Tue, 2 Sep 2008 07:59:04 -0700 (PDT)
Received: from EICONMTL.eicon.com (unknown [192.219.17.124])
by core3.amsl.com (Postfix) with ESMTP id BF32C3A6A0A
for <sigtran at ietf.org>; Tue, 2 Sep 2008 07:59:03 -0700 (PDT)
Received: from pysmail.eicon.com ([192.168.100.101]) by EICONMTL.eicon.com
with Microsoft SMTPSVC(6.0.3790.3959);
Tue, 2 Sep 2008 10:59:09 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 2 Sep 2008 10:59:07 -0400
Message-ID: <E096369D937D3A4DB271B382850C5C5F07C81F4F at pysmail.eicon.com>
In-Reply-To: <20080902140444.GA24137 at openss7.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP
Thread-Index: AckNBNxzL6R37BrTSbyyJeu3P/MAqAABBVdg
References: <E096369D937D3A4DB271B382850C5C5F07C81979 at pysmail.eicon.com>
<20080901170254.GA19609 at openss7.org>
<E096369D937D3A4DB271B382850C5C5F07C81A4C at pysmail.eicon.com>
<20080902140444.GA24137 at openss7.org>
From: "Howard May" <howard.may at dialogic.com>
To: <bidulock at openss7.org>
X-OriginalArrivalTime: 02 Sep 2008 14:59:09.0540 (UTC)
FILETIME=[741A0240:01C90D0C]
Cc: sigtran at ietf.org
Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
X-BeenThere: sigtran at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>,
<mailto:sigtran-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran at ietf.org>
List-Help: <mailto:sigtran-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>,
<mailto:sigtran-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sigtran-bounces at ietf.org
Errors-To: sigtran-bounces at ietf.org
Hi Brian,
Thanks for your response but I'm still unclear whether when the AS
becomes active M3UA should immediately consider the route to the SG/STP
as available or whether it should wait for a DAVA. I'm also unclear
whether the SG should respond to DAUD concerning the SG/STPs Point Code
or not.
Best Regards
Howard
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:bidulock at openss7.org]
> Sent: 02 September 2008 15:05
> To: Howard May
> Cc: sigtran at ietf.org
> Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
>
> Howard,
>
> I didn't say that an MTP-User at a signalling point receives an
> MTP-PAUSE for its own point code. What I was saying is that an
> MTP-User at a signalling point can always generate an MTP-TRANSFER
> primitive for a given destination regardless of whether it has
> received an MTP-PAUSE for that destination.
My concern is not with the MTP3 User but rather whether M3UA at the ASP
should consider the route to the SG/STP as available.
While an MTP user may generate MTP-TRANSFER primitives after receiving
an MTP-PAUSE I'm not sure that either ISUP or SCCP should.
Section 7.22 of Q.22 of Q.711 explains that on receipt of an MTP-PAUSE The user
should wait for an MTP_RESUME and in the mean time is not allowed to
send messages to that signalling point.
Section 2.14 of Q.764 explains that on receipt of an MTP_PAUSE ISUP
cannot send messages to the affected exchange.
>
> Also, SG do not issue DAUD, so what did you mean by "see whether
> the SG responds with DAUD"?
This was a typo, I meant to say DUNA.
>
> DAVA and DUNA are equivalent to MTP-RESUME and MTP-PAUSE in this
> situation, and they represent the status of the signalling point
> in the SS7 network. MTP does not send MTP-RESUME or MTP-PAUSE
> for its own signalling point code.
>
> Precisely when M3UA sends a DAVA and DUNA however, is largely
> part of the NIF and out of scope of the RFC. Achieving
> transparency with SS7 requires first a knowledge of how SS7
> behaves.
>
> --brian
>
> Howard May wrote: (Tue, 02 Sep 2008
04:47:26)
> > Hi,
> >
> > MTP normally generates PAUSE and RESUME indications for Routes it
> > maintains to remote signalling points. In this situation the
signalling
> > point in question is it's own signalling point for which it does not
> > normally have a route defined nor generate PAUSE and RESUME
indications.
> > Consequently I don't believe it is normal for MTP to generate a
PAUSE or
> > RESUME for this signalling point as you have described.
> >
> > Also I would expect the MTP User on the ASP to have some method
other
> > than generating User Messages to determine the route availability.
Is it
> > really the case that they have to send user messages to the SG and
wait
> > and see whether the SG responds with DAUD?
> >
> > I would expect either one or the other of the following to be
followed.
> >
> > 1) Presume available:
> > If the AS is active then M3UA on the ASP presumes the route to the
> > SG/STP is available and generates a RESUME to the AS.
> >
> > 2) Treat like any other Route:
> > The AS does not presume the route to the SG/STP is available but
must
> > treat the Signalling Point like any other by generating DAUD and
> > responding to DAVA and DUNA messages.
> >
> > Cheers
> >
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:bidulock at openss7.org]
> > Sent: 01 September 2008 18:03
> > To: Howard May
> > Cc: sigtran at ietf.org
> > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
> >
> > Howard,
> >
> > In general, there is nothing stopping an MTP User from sending a
> > message for a destination, event if it has received an MTP-PAUSE.
> > Therefore, an ASP can send a message to 'Alpha' regardless of
> > whether it has received DUNA or DAVA. MTP at the SG should treat
> > the ASP like any ohter MTP user or MTP peer and reissue a DUNA
> > (once for every 8 or 10 MTP-TRANSFER primitives for the unavailable
> > destination, or once every T8 for a peer arrangement).
> >
> > --brian
> >
> >
> > Howard May wrote: (Mon, 01 Sep 2008
10:56:53)
> > >
> > > Hi, I would value some clarification on the following:
> > >
> > >
> > > Does the M3UA protocol provision for any situation whereby an
ASP
> > can
> > > route messages for point code `Alpha' to an SG without first
> > receiving
> > > a DAVA for point code `Alpha' from the SG. Specifically if the
SG
> > > terminates messages for PC `Alpha' does M3UA presume the route
to
> > > `Alpha' from the ASP is available as soon as the ASP becomes
active
> > on
> > > that SG (without the reception of DAVA)?
> > >
> > >
> > > Or put slightly differently:
> > >
> > > When connecting to an SG/STP such as shown in Figure 1 of RFC
4666
> > > should the ASP presume to receive DAVA and DUNA indications for
the
> > > Point Code of STP1 in the same manner as it would for any other
> > Route
> > > or is the Point Code of STP1 different? Should the ASP presume
the
> > > Point Code of STP1 is available as soon as the ASP is active on
> > SG1?
> > >
> > >
> > > Best Regards
> > >
> > >
> > > Howard
> >
> > > _____________________________________________.711 explains that on receipt of an MTP-PAUSE The user
should wait for an MTP_RESUME and in the mean time is not allowed to
send messages to that signalling point.
Section 2.14 of Q.764 explains that on receipt of an MTP_PAUSE ISUP
cannot send messages to the affected exchange.
>
> Also, SG do not issue DAUD, so what did you mean by "see whether
> the SG responds with DAUD"?
This was a typo, I meant to say DUNA.
>
> DAVA and DUNA are equivalent to MTP-RESUME and MTP-PAUSE in this
> situation, and they represent the status of the signalling point
> in the SS7 network. MTP does not send MTP-RESUME or MTP-PAUSE
> for its own signalling point code.
>
> Precisely when M3UA sends a DAVA and DUNA however, is largely
> part of the NIF and out of scope of the RFC. Achieving
> transparency with SS7 requires first a knowledge of how SS7
> behaves.
>
> --brian
>
> Howard May wrote: (Tue, 02 Sep 2008
04:47:26)
> > Hi,
> >
> > MTP normally generates PAUSE and RESUME indications for Routes it
> > maintains to remote signalling points. In this situation the
signalling
> > point in question is it's own signalling point for which it does not
> > normally have a route defined nor generate PAUSE and RESUME
indications.
> > Consequently I don't believe it is normal for MTP to generate a
PAUSE or
> > RESUME for this signalling point as you have described.
> >
> > Also I would expect the MTP User on the ASP to have some method
other
> > than generating User Messages to determine the route availability.
Is it
> > really the case that they have to send user messages to the SG and
wait
> > and see whether the SG responds with DAUD?
> >
> > I would expect either one or the other of the following to be
followed.
> >
> > 1) Presume available:
> > If the AS is active then M3UA on the ASP presumes the route to the
> > SG/STP is available and generates a RESUME to the AS.
> >
> > 2) Treat like any other Route:
> > The AS does not presume the route to the SG/STP is available but
must
> > treat the Signalling Point like any other by generating DAUD and
> > responding to DAVA and DUNA messages.
> >
> > Cheers
> >
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:bidulock at openss7.org]
> > Sent: 01 September 2008 18:03
> > To: Howard May
> > Cc: sigtran at ietf.org
> > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
> >
> > Howard,
> >
> > In general, there is nothing stopping an MTP User from sending a
> > message for a destination, event if it has received an MTP-PAUSE.
> > Therefore, an ASP can send a message to 'Alpha' regardless of
> > whether it has received DUNA or DAVA. MTP at the SG should treat
> > the ASP like any ohter MTP user or MTP peer and reissue a DUNA
> > (once for every 8 or 10 MTP-TRANSFER primitives for the unavailable
> > destination, or once every T8 for a peer arrangement).
> >
> > --brian
> >
> >
> > Howard May wrote: (Mon, 01 Sep 2008
10:56:53)
> > >
> > > Hi, I would value some clarification on the following:
> > >
> > >
> > > Does the M3UA protocol provision for any situation whereby an
ASP
> > can
> > > route messages for point code `Alpha' to an SG without first
> > receiving
> > > a DAVA for point code `Alpha' from the SG. Specifically if the
SG
> > > terminates messages for PC `Alpha' does M3UA presume the route
to
> > > `Alpha' from the ASP is available as soon as the ASP becomes
active
> > on
> > > that SG (without the reception of DAVA)?
> > >
> > >
> > > Or put slightly differently:
> > >
> > > When connecting to an SG/STP such as shown in Figure 1 of RFC
4666
> > > should the ASP presume to receive DAVA and DUNA indications for
the
> > > Point Code of STP1 in the same manner as it would for any other
> > Route
> > > or is the Point Code of STP1 different? Should the ASP presume
the
> > > Point Code of STP1 is available as soon as the ASP is active on
> > SG1?
> > >
> > >
> > > Best Regards
> > >
> > >
> > > Howard
> >
> > > _______________________________________________
> > > Sigtran mailing list
> > > Sigtran at ietf.org
> > > https://www.ietf.org/mailman/listinfo/sigtran
> >
> >
> > --
> > Brian F. G. Bidulock
> > bidulock at openss7.org
> > http://www.openss7.org/
>
> --
> Brian F. G. Bidulock
> bidulock at openss7.org
> http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran at ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
__
> > > Sigtran mailing list
> > > Sigtran at ietf.org
> > > https://www.ietf.org/mailman/listinfo/sigtran
> >
> >
> > --
> > Brian F. G. Bidulock
> > bidulock at openss7.org
> > http://www.openss7.org/
>
> --
> Brian F. G. Bidulock
> bidulock at openss7.org
> http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran at ietf.org
https://www.ietf.org/mailman/listinfo/sigtran