Re: Use of two Calling Party Number IEs
Rich,
As you pointed out, the information can be passed in H.225.0 v1 when it is presented at an ISDN gateway. By extension this can be true for ISUP. Therefor, there is no need for any changes.
As I understand it, FT need was to have a secure Calling Party address presented to a gateway when routing from H.323 to SCN. If this is true, the case of information provided by an incoming ISDN gateway is trivial. It appears to be more important that the H.323 network providers also be able to add a secure address.
On the other hand, there are better security methods available in the H.323 world (tokens) such that a secure address may not be needed for gateway security.
Seperate, some IVR functions need a secure address in order to work even when a User blows a configuration.
Bob
------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------
-----Original Message----- From: Rich Bowen [mailto:rkbowen@cisco.com] Sent: Tuesday, June 13, 2000 12:53 AM To: Callaghan, Robert Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: Re: Use of two Calling Party Number IEs
Bob,
I think I understand your concern now, and I agree that there apparently has not been much consideration given to how these features would extend to H.323 terminals.
My understanding of the result of the Osaka discussion is that H.225.0 should basically state, "There can be 2 Calling Party Number IEs", which is already stated in H.246 and is allowed by the statement about Q.931 transport. Do you think FT was asking for more than this?
It sounds like you would prefer to see this change incorporated only as part of a broader solution that includes terminals. Would this broader solution change the fact that 2 Calling Party Number IEs could be present? I'm wondering if the terminal issue could be addressed separately.
- Rich
"Callaghan, Robert" wrote:
Rich,
Yes, this is allowed under the clause that allows any information arriving from an ISDN gateway to be transported over the Q.931 portion of H.225.0. It is not to be generated by any H.323 terminal. On the other hand, how many stacks would think of this.
The essence of France Telecom's proposal is to allow transport of a user provided number and a secure network provided number with ISUP and ISDN as examples. It should not be limited to ISUP or ISDN provided numbers. It should be allowed when secure network is H.323. This requires that the numbers be generated by H.323 terminals. This is contray to the clause referenced in the first paragraph. Also this only works for E.164 type numbers in that H.225.0 can only transport this type of number in the Calling Party Number Ie. Other forms of numbers (e.g. Private Number,
URL)
must be transported in ASN.1 coding. It is possible to tranport more that one number in the Calling Party Number field; but how do you mark one as user provided and the other network provided?
Bob
Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com
-----Original Message----- From: Rich Bowen [mailto:rkbowen@cisco.com] Sent: Monday, June 12, 2000 4:37 PM To: Callaghan, Robert Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: Re: Use of two Calling Party Number IEs
Bob,
Annex A/Q.951, for some good editorial reason I'm sure, is between Clauses 3 and 4 in Q.951.3.
My understanding from the discussion was that this option is already allowed in H.225.0, and that we just needed to clarify that it is allowed.
For the ISUP case, Note 1 at the bottom of Table 56 of H.246 Annex C states that two Calling Party Number IEs are sent in H.225.0 if the option is supported, or that only the generic number is forwarded if the option is not supported. For the Q.931 case, I assumed the same approach would apply.
I'm not sure I understand the issues about multiple private numbers or URLs. I don't think the scope of this contribution included URLs, etc. It was only addressing the case of receiving two calling party number IEs from the SCN.
- Rich
"Callaghan, Robert" wrote:
Rich,
We did not agree to a delivery method in Osaka. I certainly would like
to
review any proposed method before agreeing.
I could not fine Annex A/Q.951; could you help.
In all probability, it proposes the duplication of the Calling Party
Number
IE; each with individual presentation and screening controls. How does
this
map to H.225.0? How do you have private number each with individual presentation and screening controls? Does this include multiple URLs, E-mail address, etc.?
Bob
Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com
-----Original Message----- From: Rich Bowen [mailto:rkbowen@CISCO.COM] Sent: Sunday, June 11, 2000 10:24 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Use of two Calling Party Number IEs
Mr. Blin,
In Osaka, it was agreed as you proposed in TD-09 to add clarifying text to H.225.0 regarding the use of two calling party number IEs. Would the following clarification address this concern?
A note would be added to the Setup message IE table concerning use of the Calling Party Number IE that would state:
Multiple Calling Party Number IEs may be present in order to support, for example, the "Two Calling party number information elements delivery option" defined in Annex A/Q.951 or the interworking of H.323 and ISUP supplementary services as described in Annex C/H.246.
Regards, Rich
Richard K. Bowen Cisco Systems, Inc. rkbowen@cisco.com Research Triangle Park, NC
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com--
Richard K. Bowen Cisco Systems, Inc. rkbowen@cisco.com Research Triangle Park, NC
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (1)
-
Callaghan, Robert