Subject: [Sigtran] GT in Sua & Sccp

From: [email-masked]
Date: Tue, 26 Apr 2005 17:21:03 +0800

i have a question about GT1

in sua_draft-16
Nature of Address is ignored. Translation Type = Unknown
              and Numbering Plan = E.164 (value 1).

in rfc3868
Nature of Address is taken over. It is implicitly assumed     that the
Translation Type = Unknown and Numbering Plan = E.164 (value 1).

in sccp :Nature of Address can be:
  |-----+------------+-------------+---------------------------|
  | Bits| 7 6 5 4 3 2|             |                           |
  |     | 1          |             |                           |
  |-----+------------+-------------+---------------------------|
  |     | 0 0 0 0 0 0|             | unknown                   |
  |     | 0          |             |                           |
  |-----+------------+-------------+---------------------------|
  |     | 0 0 0 0 0 0|             | subscriber number         |
  |     | 1          |             |                           |
  |-----+------------+-------------+---------------------------|
  |     | 0 0 0 0 0 1|             | reserved for national use |
  |     | 0          |             |                           |
  |-----+------------+-------------+---------------------------|
  |     | 0 0 0 0 0 1|             | national       significant|
  |     | 1          |             | number                    |
  |-----+------------+-------------+---------------------------|
  |     | 0 0 0 0 1 0|             | international number      |
  |     | 0          |             |                           |
  |-----+------------+-------------+---------------------------|
  |     | 0 0 0 0 1 0| (Embedded   |                           |
  |     | 1          | image  moved|Spare                      |
  |     |     to     | to     file:|                           |
  |     | 1 1 1 1 1 1| pic11833.jpg|                           |
  |     | 1          | )           |                           |
  |     |            |             |                           |
  |-----+------------+-------------+---------------------------|

  then i warry about the principle of find gtcode in sua&sccp is not same
  for gt1

  and another question is: do sua can deal with GT the same as sccp(as q713
  4.2.3)

***********************************************
信息安全声明：本邮件包含信息归ZTE所有，
ZTE对该邮件拥有所有权利。请接收者注意
保密，未经发件人书面许可，不得向任何第
三方组织和个人透露本邮件所含信息的全部
或部分。以上声明仅适用于工作邮件。
Information Security  Notice：
The information contained in this mail is
solely property of  ZTE Corporation. 
This mail communication is confidential.
Recipients named above are obligated to
maintain secrecy and are not permitted to
disclose the contents of this communication
to others.
***********************************************
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Apr 2005 04:02:16 -0600

chen.puran,

The GTI in SUA is identical to SCCP except with regard to encoding
scheme which is predetermined in SUA.  What seems to be the problem?

(Note: you need to strip the legal stuff from the bottom of your
emails when you post to IETF mailing lists...)

--brian

[email-masked] wrote:                                                    (Tue, 26 Apr 2005 17:21:03)

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

---

From: Jay N Bhuyan <[email-masked]>
Date: Thu, 28 Apr 2005 18:43:51 -0400

Hi,

I have a question on SUA IPSP DE model. As per Section 3.4.4.1
in RFC 3868,  four messages must be exchanged between peer IPSPs for a state
change.

Consider the following scenario:

Both IPSP A and IPSP B are using IPSP DE model and are in the ASP-ACTIVE state.
IPSP A sent an ASP Inactive
message to IPSP B and received an ASP Inactive Ack message. However,
IPSP A  did not receive any ASP Inactive message from IPSP B.

My question is:
What is the status of IPSP A in IPSB B, and similarly what is the status
of IPSP B in IPSP A?

IPSP A                                                  IPSP B

    [Both the IPSPs are in the ASP-ACTIVE state (IPSP DE Model)]

   +-------------------------------ASP Inactive----------------->
   <--------------------ASP Inactive Ack------------------------+

3.4.4.1.  IPSP Considerations

   An IPSP may be considered in the ASP-INACTIVE state by a remote IPSP
   after an ASP Inactive or ASP Inactive Ack message has been received
   from it.

   Alternatively, when using IPSP DE model, an interchange of ASP
   Inactive messages from each end MUST be performed.  Four messages are
   needed for completion.

Thanks,
Jay

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 Apr 2005 21:53:13 -0600

Jay,

It was a problem with the DE model that it could become hung half way
like this.  I think the text is quite clear that it takes all 4 messages
to do the job.  2 messages is just half way.  How much half way is not
of much moment.  This is one of the reasons why the SE model is to be
used over the DE model.

--brian

Jay N Bhuyan wrote:                                  (Thu, 28 Apr 2005 18:43:51)

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