Re: 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.

Also, SG do not issue DAUD, so what did you mean by "see whether
the SG responds with DAUD"?

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:[email protected]] 
> Sent: 01 September 2008 18:03
> To: Howard May
> Cc: [email protected]
> 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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/sigtran
> 
> 
> -- 
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/

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