Issues for IN/CORBA FTF mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 2583: Title does not cover the use of SS7 as signaling transpor
Issue 2584: Section number: 3.3.4 and elsewhere
Issue 2585: Section number: 3.3.4 make factory creation operations conform to the IDL
Issue 2586: Sec.: 3.5.1.1, item 4 plus appropriate section of interaction translation
Issue 2588: Section number: 3.5.1.1, item 3
Issue 2589: How can we bound the range of invoke ids in the IDL?
Issue 2590: It should be possible to have negative invoke ids
Issue 2591: Section number: 4.2.1
Issue 2592: Problem: Why is AssociationId a string?
Issue 2593: The current text for DialogFlowCtr is for outgoing only
Issue 2594: There is a difference between the responder and initiator interfaces
Issue 2595: Section 4.3.2.1 Title and text should be changed
Issue 2596: Section 4.7.1: RelativeRoundTripPolicy
Issue 2597: Shouldn’t this section really be called TC Service Interface?
Issue 2598: Section number: 5.2 and other sub-sections
Issue 2599: Section number: 5.4.1
Issue 2600: Shouldn’t it be typedef string CORBA::ScopedName?
Issue 2601: Section number: Fig. 27
Issue 2602: Could SIOP be changed to 7IOP, pronounced "seven-up"?
Issue 2603: Should SIOP version number start with 1.2?
Issue 2604: Section number: 6.2.2
Issue 2605: Problem: There is no way to send dialogue data in a continue confirm.
Issue 2606: Section number: 5
Issue 2607: Section number: 2.3
Issue 2915: Use of InvokeId as the type name for both invoke id and link id.
Issue 2916: When does a multiassociation TcUse know that it has been finished with?
Issue 2917: Why one to one association between a TcPduUser and TcPduProvider interface?
Issue 2918: Specification Translation from ASN to IDL issue
Issue 2919: TcPdu User and Provider interfaces
Issue 2982: use of the SSN number in the 1988 TCAP version
Issue 3184: Allow GIOP 1.3 messages to be transported.
Issue 3313: There is currently no valuetype support in SIOP.
Issue 3314: Missing definition on security tags in the SIOP

Issue 2583: Title does not cover the use of SS7 as signaling transpor (incorba-ftf)

Summary: Problem: Title does not cover the use of SS7 as signaling transport. This case is 
 not a TC interworking.

Summary: Problem: There is a general problem on how to specify sending an empty 
 Transaction PDU, such as an empty BEGIN, or an empty CONTINUE. "Empty" 
 means just the Transaction portion without ROS components. This problem has 
 to be addressed for sending an empty Transaction PDU from the CORBA side, 
 as well as what to do when such a PDU is received from the legacy domain.

Summary: Problem: make factory creation operations conform to the IDL style guide
 
 Proposed solution: change the capitalization and put in underscores between 
 words

Summary: Section number: 3.5.1.1, item 4 plus appropriate section of interaction translation
 
 Problem: How to handle the sending of an empty RESULT and the reception of 
 such a component.
 
 Proposed solution: Obviously no way to change the IDL from void. Need 
 something in the TC Repository for use by a gateway in deciding what to do.
 

Summary: Issue: 5
 
 Section number: 3.5.1.1, item 3
 
 Problem: We have mistakenly associated TcLinkedContext with the operation 
 which has the LINKED keyword rather than the actual linked operation, i.e., the 
 operations appearing following the LINKED keyword

Summary: Section number: 4.2.1
 
 Problem: How can we bound the range of invoke ids in the IDL?  Q773 requires 
 invoke ids in the range -128 to 127. ROS has no limits.

Summary: It should be possible to have negative invoke ids.

 change it to signed. But see issue 6 also.

Summary: Problem: It is not necessary to have uniqueness of Invoke Ids within a dialog. 
 The invoke id can be reused as soon as it is no longer active. 
 
 Proposed solution: Put in text following the discussion of management of invoke 
 ids in the TC spec.

Summary: Section number: 4.2.1
 
 Problem:  Why is AssociationId a string? Should one explore the possibility of 
 using a combination of values supplied by both the initator and responder. 
 Strings do not seem to be the most scalable solution.

Summary: Section number: 4.2.1
 
 Problem: The current text for DialogFlowCtr is for outgoing only. It should be  
 updated to reflect incoming messages from the legacy domain.

Summary: Section number: 4.2.2
 
 Problem: There is a difference between the responder and initiator interfaces 
 because the initator cannot support the new association operations.

Summary: Section number: 4.3.1.2
 
 Problem: Title and text should be changed to reflect that it is dealing with creating 
 an association rather than initiating a dialog.

Summary: Section number: 4.7.1
 
 Problem: Is it necessary to indicate that RelativeRoundTripPolicy is not 
 propogated to the server? Also does TC interworking require the support of the 
 priority policies?

Summary: Section number: 5
 
 Problem: Shouldn’t this section really be called TC Service Interface because it 
 really provides an IDL version of Q.771? Note that this requires changing the 
 names of various interfaces by removing the word Pdu, which should be 
 reasonably simple.
 

Summary: Section number: 5.2 and other sub-sections
 
 Problem: The encapsulation BerData could potentially hold ASN.1 encoded via 
 other rules like PER. So is this name misleading, or too restrictive?
 
 Proposed solution: One choice is EncodedData.

Summary: Section number: 5.4.1
 
 Problem: DialogPortion should be a union rather than a struct. The complete IDL 
 is correct.

Summary: Section number: 7.1, page 108
 
 Problem: Shouldn’t it be typedef string CORBA::ScopedName?

 received issue

Summary: Section number: Fig. 27
 
 Problem: Shouldn’t GwTcPduHandler be replaced by GwTcPduProvider?

 received issue

Summary: Section number: 6
 
 Problem: Could SIOP be changed to 7IOP, pronounced "seven-up"?
 
 Proposed solution: 
 
 Rationale: The S in SIOP may be mistaken for Security.

 The S in SIOP may be mistaken for Security.

Summary: Section number: 6.1
 
 Problem: Should SIOP version number start  with 1.2? 
 
 Proposed solution: 
 
 Rationale: This would allow a quick recognition of the highest GIOP version supported by 
 this version of SIOP.
 

 This would allow a quick recognition of the highest GIOP version supported by 

Summary: Section number: 6.2.2
 
 Problem: sccp_version should be changed to SIOP_version. Also the word 
 "agent" should be changed to "server."

Summary: Section number: 5.4.4
 
 Problem: There is no way to send dialogue data in a continue confirm.
 

Summary: Section number: 5
 
 Problem: There is no way to associate more than one instance of a TcPduUser 
 with a GT/AC pair for incoming SS7 messages.

Summary: Problem: Use UML to express relationship of interfaces.

The idl is

    struct TcLinkedContext {
        DialogFlowCtr ctr;
        InvokeId ivk_id;
        InvokeId lnk_id;
        AssociationId a_id;
    };

While it is correct that these are both of the same type, the name of the type
could be confusing.

The creation of a TcUser interface with multiple associations does not have
a standardised way for destruction.

Proposed solutions

1. Add a destroy() method to TcUser
2. Explicitly state in the RFP that the CosLifeCycle::destroy() method should
be called once the object is no longer required.

There is an assumption in the design that there is a one to one
association between a TcPduUser and a TcPduProvider
during a TC Session. This is enforced in the IDL through the
call

TcPduProvider::get_dialog_id()

and the factory call

TcPduProvider create_tc_pdu_provider(
     in TcPduUser user,
     out DialogId d_id)
raises(NoMoreDialogs);

Since the TcPduUser reference (or some sort of reference)
is not passed over in get_dialog_id(), the only conclusion
is that the reference has to be the one passed over in the
create, and therefore that each TcPduProvider is tied to
one and only one TcPduUser.

The Specification Translation from ASN to IDL does not appear to
require that each OPERATION carries a NoMoreAssociations exception.

This is necessary if the use of DialogFlowCtr can implicitly create a new
association during a call on an object that supports multiple associations.

As the interfaces currently stand, there is a minimum of 5 CORBA calls
per transaction
1. either TcPduProvider::get_dialog_id
    or TcPduProviderFactory::create_tc_pdu_provider
2. TcPduProvider::invoke_req
3. TcPduProvider::begin_req
4. TcPduUser::end_ind
5. TcPduUser::result_l_ind

Given that a CORBA call is about 1 millisecond on average,
this makes for a highly inefficient interface from a high-performance
perspective,
and renders the distribution of these interfaces undesirable, and the
use of the TcPduProvider/User interfaces unlikely in a real system.

Ideally this should be reduced to a minimum of 2 CORBA calls, one for a call
going out, and one for the reply.

As far as I can see when using the 1988 TCAP version the submission
does not seems to handle the case where the subsystem number (SSN) is
used to seperate between several TC-User protcols per GT (typically
protocols from different vendors). The naming tree proposed for the
1988 TCAP protocol can only store one TC-User protocol per GT, that is
only one DefAc per GT can be stored (see section 4.3.1.1 in the
proposal).

The use of the SSN number for this purpose is explained in chapter
4.2.3 in the second paragraph in the ITU Recommendation Q.775.

It should be easy to fix this as one only have to use the same naming
tree structure proposed for the 1993 TCAP version in these cases.

Align SIOP definition with GIOP 1.3 of CORBA2.3.1. 

Problem: SIOP is currently defined to carry GIOP messages with version 1.2
and lower.

Proposed Solution: Allow GIOP 1.3 messages to be transported. 

There are security tags mentioned in the SIOP 
document but no definition of how to use them is ever given.