Subject: M2UA messages

From: Ming Lin <[email-masked]>
Date: Tue, 25 Sep 2001 15:47:30 +0800

Hi all,

Is M2UA in IESG last call?
Sorry to bring up the following issues about m2ua messages so late.

1.Do we need release confirm message?
It could not be mapped to ITU primitive,
because there is only OUT OF SERVICE primitve,
even if the link is released by local.

2.Do we need state confirm message?
There is no ITU primitive mapped to this message.
I think MTP3 could handle the situation without conform
in traditional SS7 so it also can handle the situation without this message.

3.Do we need retrieve confirm message?
There are retieve indication and retieve complete ITU primitve,
but no retieve confirm.
I also think MTP3 could handle the failure situation without this message.

I propose to remove this three messages in order to
make 1:1 mapping between messages and ITU primitives like IUA.

Please corrected me.

Thanks&Regards
Ming Lin

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Jacob Heitz <[email-masked]>
Date: Tue, 25 Sep 2001 06:58:19 -0700

I could agree to this.

Ming Lin wrote:
> You are currently subscribed to sigtran as: [email-masked]

-- 
// Jacob Heitz, Planet of the APX. Tel:510-747-2917

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 25 Sep 2001 10:14:17 -0400

Ming,

M2UA v10 is not in IESG last call yet, but hopefully it will be soon.  Therefore,
the issues you raise are not "late".

See below for some comments.

Ken

>even if the link is released by local.

We could consider removing this message.  Any other opinions?

>in traditional SS7 so it also can handle the situation without this message.

While there is no primitive to map the State Confirm to, it is useful
to confirm the completion of Audit.  An ASP M2UA could also use
it to validate the receipt of State Request.

>I also think MTP3 could handle the failure situation without this message.

The Retreival confirm does pass back important information.  There
is a need to pass back bsn and failure situation.  Why change the
procedure now?

>You are currently subscribed to sigtran as: [email-masked]

---

---

From: Ming Lin <[email-masked]>
Date: Wed, 26 Sep 2001 09:47:59 +0800

Hi Ken,
Please see the comments below,

>it to validate the receipt of State Request.

Do you mean State Confirm is only used to confirm state audit request?
And it is also not useful, because the State Audit Request message could
be silently discarded if it is invalid, if it is valid SGP will respond
Establish Cfm, Release Ind or other,
so ASP should not wait for State Confirm.

If State Confirm is also used for other state request,
M2UA in ASP side will not know how to process this message,
because there is not ITU primitive mapped to this message.

>is a need to pass back bsn and failure situation.  Why change the

Sorry, I have not express clear here.
The Retrieve here Retrieve message, not Retrieve BSNT.
Should we respond Retrieve BSNT with retrieve indication,
or break retrieve request to two messages?
Retrieve Message Request
Retrieve Message Indication
Retrieve Message Complete
Retrieve BSNT Request
Retrieve BSNT Confirm/Indication

>>To unsubscribe send a blank email to
[email-masked]
>
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked]

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 25 Sep 2001 22:49:38 -0400

Ming,

Please see below.

Ken

>so ASP should not wait for State Confirm.

I was providing an example of its use.  The State Confirm can be useful
to an ASP to know when the Audit is complete.

>because there is not ITU primitive mapped to this message.

M2UA on the SG would not need a primitive to send the State
Confirm.  It would send the State Confirm after it processed the
State Request.

>Retrieve BSNT Confirm/Indication

I don't see a need to make a change at this point in time. 

---

---

From: Ming Lin <[email-masked]>
Date: Wed, 26 Sep 2001 11:21:57 +0800

Hi ken,
Please see comments below..

skip....

>to an ASP to know when the Audit is complete.

What is the useness that ASP know when the Audit is complete?
After ASP sends Audit, it will receive Establis Cfm, Release or other
message,
and process these messages as normal despite whether State Audit is sent.

>Confirm.  It would send the State Confirm after it processed the

I means M2UA on the ASP will not know how to process
when it receive State Confirm, because these is not primitve to map.

>I don't see a need to make a change at this point in time.

Ok, should we just declare that retrieve confirm is only used
to respond to retrieve request with ACTION_RTRV_BSN.
And when ASP receives retrieve failure, it will not know how
to indication MTP3 because these is not such primitive.

Thanks
Ming Lin

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 25 Sep 2001 23:31:06 -0500

Ken,

Ken Morneault wrote:                                          (Tue, 25 Sep 2001 10:14:17)
> We could consider removing this message.  Any other opinions?

Release confirm maps to AA-RELEASE_confirm per Table 3/Q.2140.
Please do not remove it.

> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 25 Sep 2001 23:42:08 -0500

Ken,

Release confirm is necessary for Q.2140/SSCOP compatible
implementations.

State confirm is necessary to indicate
the successful completion of actions not revealed by the
other messages (e.g., that LPO is set, or a Resume has
been processed).  This is necessary for synchronous
operation of some signals.  It also makes sense to detect
a hung or congested M2UA peer.

Retrieve confirm is necessary to distinguish between failure
to retrieve and retrieval with no messages.

All three are necessary.  There is no need to make a change
to any of these procedures at this point.

--brian

Ken Morneault wrote:                          (Tue, 25 Sep 2001 22:49:38)

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

---

---

From: Ken Morneault <[email-masked]>
Date: Fri, 28 Sep 2001 10:54:30 -0400

Brian,

I agree.  Ming - I think we should move forward with 
draft v10.

Ken

---