Dear Mr. Mi , Thank you for following up ! I took the liberty of replying to you over the reflectors, since many people are interested:
.What's the conclusion for your contribution?
TD-97 (Proposal to simplify the functional architecture for IN support of IP Networks) was the basis for discussion in Manchester and was followed by an editing session of SG11 baseline. A liasion including the result of the updated baseline doc. was sent to SG16 in APC-1602 (attached zip file) (See attached file: APC-1602.zip)
.What kind of service does the interface "H.323 service control" between MGC and GK refer to? Is it related to MGC originated IPT IN-call (i.e.the call is coming from PSTN side)?
The diagram you refer to is attached for everyone's convenience (IPT-IN.gif) (See attached file: IPT-IN.gif)
- In some ways this interface resembles the TCAP interface between the SSF to the SCP: it allows for the IPT service controller (the GK) to instruct the GW on what to do with an incoming call (which may originate in IP or in PSTN). As the diagram depicts, the basic support already exists in RAS, however SG16, as well as some other organizations, have contemplated on expanding it. This proposed interface has not yet materialized.
.To my current understanding, IPT IN-call, for example 800 or 300 (calling card) calls, is of value only for H.323 terminal originated call. There is no scenario for MGC originated IPT IN-call. Is that the case?
The typical scenario for a terminal originated call is a PC user, while a GW originated call is for a calling card service. There is no difference between the two for this purpose: The originating endpoint (whether a terminal or a GW), requests the GK to provide the routing information (address, security token, etc) for a destination GW that supports the requested E.164 number. The problem that "IF1" (see diagram) needs to solve, is to allow the GK to consult the IN database for making such decisions. At the same time, it may prove beneficial for the SCP to consult with the GK in a mirrored scenario (assuming the GK based network has a meaningful service knowledge). The trivial example, is off course, the GK's knowledge of the registered endpoints (=logged in users).
Finally, please note that in parallel to SG11 work, which aims to define IP interworking for CS-4, SG16 is aiming to define IPT interworking with CS-1, with zero changes to CS-1, and minimal changes to H.323. Please take a look at my editor's web page, which contains links to the relevant documents: http://people.itu.int/~michaely/
Contributions are solicited !
Sincerely, Boaz Michaely.
mizk mizk@em.njupt.edu.cn on 23/10/99 10:24:29 PM
To: Michaely Boaz boaz@vocaltec.com cc: (bcc: Boaz Michaely) Subject: IN-IPT interworking issue
Dear Mr.Boaz:
I read your contribution TD97 on IN-IPT interworking at SG11/Q4,5&22 Manchester meeting. It interests me a lot because I have been actively involved in IN/Internet interworking issue at SG11/Q5 from the very beginning. My two contributions were the main sources of TD-GEN11/123 and its addendum. Since I didn't attend to Manchester meeting, I would like you to give some information on the following points:
.What's the conclusion for your contribution?
.What kind of service does the interface "H.323 service control" between MGC and GK refer to? Is it related to MGC originated IPT IN-call (i.e.the call is coming from PSTN side)?
.To my current understanding, IPT IN-call, for example 800 or 300 (calling card) calls, is of value only for H.323 terminal originated call. There is no scenario for MGC originated IPT IN-call. Is that the case?
Thank you in advance for your information.
Best regards,
Zhengkun Mi delegate to SG11 MII(formerly MPT), China
