- sg16-avd - lists.packetizer.com

Re: Gateway Decomposition
by Callaghan, Robert 16 Oct '98

16 Oct '98

Mark, Please include me. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information & Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)Siemenscom.com ------------------------------------------------------------------ -----Original Message----- From: Mark Reid [mailto:mreid@VIDEOSERVER.COM] Sent: Friday, October 16, 1998 4:53 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Gateway Decomposition Dear Colleagues, I would like to invite you to participate in an audio call, Tuesday October 20th from 11AM to 1PM EST to discuss our work plan for the study of gateway decomposition as outlined in TD 89 (WP2). The goals of the audio call will be to identify what work items we need to completed and in what order should we attack them. Once we have an agreed to work plan, we can talk about building an architecture document and the specific requirements of each interface. As a place to start the discussions, I think we need the following (referenced to TD 89): New Protocols: ***************** Interface A - Device Control Interface New H.246 Annexes: ************************ 1) H.323 to Voice/Voiceband Terminals = The breakdown of the media. How DTMF is converted to/from UserInputIndication messages, etc. (There is a draft of this in the current H.246 Annex B) 2) H.323 to SS7 (Similar to Q.699 - a Q.931 to ISUP conversion spec) 3) H.323 to Q.931 (Similar to the section in Annex A for H.320) Interface B, C, D ******************** For the Proposed Interfaces B, C, and D. Given that the messages passing across these interfaces must reflect all of the content of the signaling that the respective signaling functions receive from and send to extern entities, aren't these protocols modified or extended ISUP for Interface D, modified or extended Q.931 for Interface C, and modified or extended H.225 for Interface B? For C & D, can they be the real protocols if carried on a T1 and some derivation of them if running over TCP/IP? Please try and get all attendee requests in by Monday the 19th at 12:00 Noon EST so that I can make the proper arrangements. I will send port assignments later that day. Here is a summary of attendees so far: 1) G. Thom 2) S. Nayak 3) R. Badri 4) P Kallur 5) K. Hedayat 6) R Spitzer 7) R Chopra 8) A Amir 9) R Even 10) H Liu 11) J Yeh 12) R Radhika 13) B Bell 14) T Taylor 15) G Freundlich 16) M Reid/B Hill/G Kajos All comments welcome, Mark Reid 1-781-505-2368 mreid(a)videoserver.com Bryan Hill 1-781-505-2159 bhill(a)videoserver.com

1 0

None
by Rahul Chopra 16 Oct '98

16 Oct '98

Mark: Would appreciate if you can please let me know the congf. bridge details. Thanks. Rahul > -----Original Message----- > From: Mark Reid [SMTP:mreid@VIDEOSERVER.COM] > Sent: Friday, October 16, 1998 4:53 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: > > Dear Colleagues, > > I would like to invite you to participate in an audio call, Tuesday > October > 20th from 11AM to 1PM EST to discuss our work plan for the study of > gateway > decomposition as outlined in TD 89 (WP2). > > The goals of the audio call will be to identify what work items we need to > completed and in what order should we attack them. Once we have an agreed > to > work plan, we can talk about building an architecture document and the > specific requirements of each interface. > > As a place to start the discussions, I think we need the following > (referenced to TD 89): > > New Protocols: > ***************** > Interface A - Device Control Interface > > New H.246 Annexes: > ************************ > 1) H.323 to Voice/Voiceband Terminals = The breakdown of the media. How > DTMF > is converted to/from UserInputIndication messages, etc. (There is a draft > of > this in the current H.246 Annex B) > 2) H.323 to SS7 (Similar to Q.699 - a Q.931 to ISUP conversion spec) > 3) H.323 to Q.931 (Similar to the section in Annex A for H.320) > > Interface B, C, D > ******************** > For the Proposed Interfaces B, C, and D. Given that the messages passing > across these interfaces must reflect all of the content of the signaling > that the respective signaling functions receive from and send to extern > entities, aren't these protocols modified or extended ISUP for Interface > D, > modified or extended Q.931 for Interface C, and modified or extended H.225 > for Interface B? For C & D, can they be the real protocols if carried on a > T1 and some derivation of them if running over TCP/IP? > > Please try and get all attendee requests in by Monday the 19th at 12:00 > Noon > EST so that I can make the proper arrangements. I will send port > assignments > later that day. Here is a summary of attendees so far: > > 1) G. Thom > 2) S. Nayak > 3) R. Badri > 4) P Kallur > 5) K. Hedayat > 6) R Spitzer > 7) R Chopra > 8) A Amir > 9) R Even > 10) H Liu > 11) J Yeh > 12) R Radhika > 13) B Bell > 14) T Taylor > 15) G Freundlich > 16) M Reid/B Hill/G Kajos > > All comments welcome, > > Mark Reid > 1-781-505-2368 > mreid(a)videoserver.com > > Bryan Hill > 1-781-505-2159 > bhill(a)videoserver.com

1 0

Re: Contact Info requested
by Kaynam Hedayat 16 Oct '98

16 Oct '98

Mr. Taylor, Please include me in the call as well. Thank you. Kaynam Hedayat PictureTel Corporation Rahul Chopra <rchopra(a)NETSPEAK.COM> on 10/16/98 09:36:36 AM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)MAILBAG.INTEL.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM cc: (bcc: Kaynam Hedayat/PicTel) Subject: Re: Contact Info requested Would appreciate if you included me. Thanks. Rahul 561-347-2493 > > Jenn > > -------------------------------------------------------------------------- > ------ > ______ Jenn Yeh, Staff Engineer > /_____/\ > /_____\\ \ SUN Microsystems Inc. > /_____\ \\ / 140 Scott Drive, MS UMPK03-213 > /_____/ \/ / / Menlo Park, CA 94025 > /_____/ / \//\ > \_____\//\ / / email: jenn.yeh(a)eng.sun.com > \_____/ / /\ / phone: +1.650.688.9404 > \_____/ \\ \ fax: +1.650-688-9007 > \_____\ \\ > \_____\/ > > > > -------------------------------------------------------------------------- > ------ > > > > MIME-Version: 1.0 > > Date: Thu, 15 Oct 1998 14:34:41 -0400 > > From: "Roy, Radhika R, ALINT" <rrroy(a)ATT.COM> > > Subject: Re: Contact Info requested > > To: ITU-SG16(a)mailbag.cps.intel.com > > > > Tom: > > > > Please include me in the conference call. > > > > Thanks, > > > > Radhika R. Roy > > AT&T, USA > > > > Tel: +1 732 949 8657 > > > > > > > > > > > ---------- > > > From: Tom-PT Taylor[SMTP:Tom-PT.Taylor.taylor@NT.COM] > > > Reply To: Mailing list for parties associated with ITU-T Study > Group > > > 16 > > > Sent: Thursday, October 15, 1998 12:53 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Contact Info requested > > > > > > What's the contact info for Mark Reid? He was supposed to set up a > > > kick-off > > > conference call for the Gateway Decomposition study. I wanted to > check on > > > status and set up the call myself if he is too busy. > > > > > > Tom Taylor > > > E-mail: taylor(a)nortel.com (internally Tom-PT Taylor) > > > Tel.: +1 613 765 4167 (internally 395-4167) > > > FAX: +1 613 763 7236 (internally 393-7236) > > >

3 2

Re: Contact Info requested
by Prasad Kallur 16 Oct '98

16 Oct '98

Hi, Please include me on the list too. Thanks, Prasad Kallur Prasad Kallur, Trillium Digital Systems Engineering Manager, 12100, Wilshire Blvd, Tel : (310)-442-9222, Suite 1800, LA, CA-90025 Fax : (310)-442-1162, prasad(a)trillim.com Web:http://www.trillium.com -----Original Message----- From: Roy Spitzer [mailto:rspitzer@TELOGY.COM] Sent: Friday, October 16, 1998 7:47 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Contact Info requested Please include me in on the conference call and any distribution list for Gateway Decomposition. Regards, Roy Roy Spitzer Telogy Networks Phone (301) 515-6531 20250 Century Boulevard Fax: (301) 515-7954 Germantown, Maryland 20874 email: rspitzer(a)telogy.com

1 0

Re: Contact Info requested
by Roy Spitzer 16 Oct '98

16 Oct '98

Please include me in on the conference call and any distribution list for Gateway Decomposition. Regards, Roy Roy Spitzer Telogy Networks Phone (301) 515-6531 20250 Century Boulevard Fax: (301) 515-7954 Germantown, Maryland 20874 email: rspitzer(a)telogy.com

1 0

Re: Contact Info requested
by Rahul Chopra 16 Oct '98

16 Oct '98

Would appreciate if you included me. Thanks. Rahul 561-347-2493 > > Jenn > > -------------------------------------------------------------------------- > ------ > ______ Jenn Yeh, Staff Engineer > /_____/\ > /_____\\ \ SUN Microsystems Inc. > /_____\ \\ / 140 Scott Drive, MS UMPK03-213 > /_____/ \/ / / Menlo Park, CA 94025 > /_____/ / \//\ > \_____\//\ / / email: jenn.yeh(a)eng.sun.com > \_____/ / /\ / phone: +1.650.688.9404 > \_____/ \\ \ fax: +1.650-688-9007 > \_____\ \\ > \_____\/ > > > > -------------------------------------------------------------------------- > ------ > > > > MIME-Version: 1.0 > > Date: Thu, 15 Oct 1998 14:34:41 -0400 > > From: "Roy, Radhika R, ALINT" <rrroy(a)ATT.COM> > > Subject: Re: Contact Info requested > > To: ITU-SG16(a)mailbag.cps.intel.com > > > > Tom: > > > > Please include me in the conference call. > > > > Thanks, > > > > Radhika R. Roy > > AT&T, USA > > > > Tel: +1 732 949 8657 > > > > > > > > > > > ---------- > > > From: Tom-PT Taylor[SMTP:Tom-PT.Taylor.taylor@NT.COM] > > > Reply To: Mailing list for parties associated with ITU-T Study > Group > > > 16 > > > Sent: Thursday, October 15, 1998 12:53 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Contact Info requested > > > > > > What's the contact info for Mark Reid? He was supposed to set up a > > > kick-off > > > conference call for the Gateway Decomposition study. I wanted to > check on > > > status and set up the call myself if he is too busy. > > > > > > Tom Taylor > > > E-mail: taylor(a)nortel.com (internally Tom-PT Taylor) > > > Tel.: +1 613 765 4167 (internally 395-4167) > > > FAX: +1 613 763 7236 (internally 393-7236) > > >

1 0

Re: Contact Info requested
by George Kajos 16 Oct '98

16 Oct '98

Hello Tom, Mark Reid's phone number is 781-505-2368. His email address is mreid(a)videoserver.com. You should call him and try to agree on a day/time for a regular call. Thanks, George Kajos gkajos(a)videoserver.com VideoServer, Inc. 63 Third Avenue Burlington, MA. 01803 781-505-2193 (tel) 781-505-2101 (fax) -----Original Message----- From: Tom-PT Taylor [mailto:Tom-PT.Taylor.taylor@NT.COM] Sent: Thursday, October 15, 1998 12:54 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Contact Info requested What's the contact info for Mark Reid? He was supposed to set up a kick-off conference call for the Gateway Decomposition study. I wanted to check on status and set up the call myself if he is too busy. Tom Taylor E-mail: taylor(a)nortel.com (internally Tom-PT Taylor) Tel.: +1 613 765 4167 (internally 395-4167) FAX: +1 613 763 7236 (internally 393-7236)

1 0

Re: Contact Info requested
by Ami Amir 16 Oct '98

16 Oct '98

Hi Same please Ami -----Original Message----- From: Roni Even [SMTP:Roni_e@ACCORD.CO.IL] Sent: Friday, October 16, 1998 12:17 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Contact Info requested Hi, Please include me in the call Thanks Roni Even ********************************************** Roni Even VP Product Marketing Accord Video Telecommunication Email: roni_e(a)accord.co.il Tel: +972-3-9251412 Fax: +972-3-9211571 *************************************************** > -----Original Message----- > From: Tom-PT Taylor [SMTP:Tom-PT.Taylor.taylor@NT.COM] > Sent: Thursday, October 15, 1998 6:54 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Contact Info requested > > What's the contact info for Mark Reid? He was supposed to set up a > kick-off > conference call for the Gateway Decomposition study. I wanted to > check on > status and set up the call myself if he is too busy. > > Tom Taylor > E-mail: taylor(a)nortel.com (internally Tom-PT Taylor) > Tel.: +1 613 765 4167 (internally 395-4167) > FAX: +1 613 763 7236 (internally 393-7236)

1 0

Re: Contact Info requested
by Roni Even 16 Oct '98

16 Oct '98

Hi, Please include me in the call Thanks Roni Even ********************************************** Roni Even VP Product Marketing Accord Video Telecommunication Email: roni_e(a)accord.co.il Tel: +972-3-9251412 Fax: +972-3-9211571 *************************************************** > -----Original Message----- > From: Tom-PT Taylor [SMTP:Tom-PT.Taylor.taylor@NT.COM] > Sent: Thursday, October 15, 1998 6:54 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Contact Info requested > > What's the contact info for Mark Reid? He was supposed to set up a > kick-off > conference call for the Gateway Decomposition study. I wanted to > check on > status and set up the call myself if he is too busy. > > Tom Taylor > E-mail: taylor(a)nortel.com (internally Tom-PT Taylor) > Tel.: +1 613 765 4167 (internally 395-4167) > FAX: +1 613 763 7236 (internally 393-7236)

2 1

Contact Info requested
by Tom-PT Taylor 16 Oct '98

16 Oct '98

What's the contact info for Mark Reid? He was supposed to set up a kick-off conference call for the Gateway Decomposition study. I wanted to check on status and set up the call myself if he is too busy. Tom Taylor E-mail: taylor(a)nortel.com (internally Tom-PT Taylor) Tel.: +1 613 765 4167 (internally 395-4167) FAX: +1 613 763 7236 (internally 393-7236)

2 1

Re: Contact Info requested
by Bell, Bob 15 Oct '98

15 Oct '98

I forgot to include this. Mark Reid VideoServer Inc 781-505-2368 (tele) mreid(a)videoserver.com -----Original Message----- From: Tom-PT Taylor [mailto:Tom-PT.Taylor.taylor@NT.COM] Sent: Thursday, October 15, 1998 10:54 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Contact Info requested What's the contact info for Mark Reid? He was supposed to set up a kick-off conference call for the Gateway Decomposition study. I wanted to check on status and set up the call myself if he is too busy. Tom Taylor E-mail: taylor(a)nortel.com (internally Tom-PT Taylor) Tel.: +1 613 765 4167 (internally 395-4167) FAX: +1 613 763 7236 (internally 393-7236) ------------------------------------------------------------------ This message was spam-checked by an evaluation copy of MailShield. See http://www.mailshield.com for more information.

2 1

Border Element
by William Pimentel 15 Oct '98

15 Oct '98

I have some questions regarding the border element (BE): Is the BE administer by a GK? in this sense does it belong to any particular zone within the admin domain? If it isn't administered then is this jerarquical diagram correct?: BE ________|_________ | | | GK GK BE / | \ T MCU GW This would mean that the BE is another H.323 entity, right? Thanks to those who can shed some light on this. -- William Pimentel w-piment(a)uniandes.edu.co

2 1

Re: Contact Info requested
by Jenn Yeh 15 Oct '98

15 Oct '98

Tom: Please also include me. Thanks, Jenn -------------------------------------------------------------------------------- ______ Jenn Yeh, Staff Engineer /_____/\ /_____\\ \ SUN Microsystems Inc. /_____\ \\ / 140 Scott Drive, MS UMPK03-213 /_____/ \/ / / Menlo Park, CA 94025 /_____/ / \//\ \_____\//\ / / email: jenn.yeh(a)eng.sun.com \_____/ / /\ / phone: +1.650.688.9404 \_____/ \\ \ fax: +1.650-688-9007 \_____\ \\ \_____\/ -------------------------------------------------------------------------------- > MIME-Version: 1.0 > Date: Thu, 15 Oct 1998 14:34:41 -0400 > From: "Roy, Radhika R, ALINT" <rrroy(a)ATT.COM> > Subject: Re: Contact Info requested > To: ITU-SG16(a)mailbag.cps.intel.com > > Tom: > > Please include me in the conference call. > > Thanks, > > Radhika R. Roy > AT&T, USA > > Tel: +1 732 949 8657 > > > > > > ---------- > > From: Tom-PT Taylor[SMTP:Tom-PT.Taylor.taylor@NT.COM] > > Reply To: Mailing list for parties associated with ITU-T Study Group > > 16 > > Sent: Thursday, October 15, 1998 12:53 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Contact Info requested > > > > What's the contact info for Mark Reid? He was supposed to set up a > > kick-off > > conference call for the Gateway Decomposition study. I wanted to check on > > status and set up the call myself if he is too busy. > > > > Tom Taylor > > E-mail: taylor(a)nortel.com (internally Tom-PT Taylor) > > Tel.: +1 613 765 4167 (internally 395-4167) > > FAX: +1 613 763 7236 (internally 393-7236) > >

1 0

CRV/Call Identifiers in RAS reply messages
by Kishore Babu Ramisetty 15 Oct '98

15 Oct '98

Hi, Is there any reason why CRV/Call Identifier is not present in RAS replies (that can be associated with a call) like ACF/BCF etc. Of course, the association can be got from sequence numbers but having a call identifier would lead to slightly simpler implementations (by obviating the need to maintain the mapping between sequence numbers and call identifier). Also, insertion of identifier at the GateKeeper end should be simple. -Kishore.

1 0

Re: Contact Info requested
by Roy, Radhika R, ALINT 15 Oct '98

15 Oct '98

Tom: Please include me in the conference call. Thanks, Radhika R. Roy AT&T, USA Tel: +1 732 949 8657 > ---------- > From: Tom-PT Taylor[SMTP:Tom-PT.Taylor.taylor@NT.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Thursday, October 15, 1998 12:53 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Contact Info requested > > What's the contact info for Mark Reid? He was supposed to set up a > kick-off > conference call for the Gateway Decomposition study. I wanted to check on > status and set up the call myself if he is too busy. > > Tom Taylor > E-mail: taylor(a)nortel.com (internally Tom-PT Taylor) > Tel.: +1 613 765 4167 (internally 395-4167) > FAX: +1 613 763 7236 (internally 393-7236) >

1 0

Re: Contact Info requested
by Bell, Bob 15 Oct '98

15 Oct '98

Tom - Could you please include me in the conference call? Thanks ---- Bob Bell -----Original Message----- From: Tom-PT Taylor [mailto:Tom-PT.Taylor.taylor@NT.COM] Sent: Thursday, October 15, 1998 10:54 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Contact Info requested What's the contact info for Mark Reid? He was supposed to set up a kick-off conference call for the Gateway Decomposition study. I wanted to check on status and set up the call myself if he is too busy. Tom Taylor E-mail: taylor(a)nortel.com (internally Tom-PT Taylor) Tel.: +1 613 765 4167 (internally 395-4167) FAX: +1 613 763 7236 (internally 393-7236) ------------------------------------------------------------------ This message was spam-checked by an evaluation copy of MailShield. See http://www.mailshield.com for more information.

1 0

Re: I invite you to an important session on Voice over IP
by Nancy-M Greene 15 Oct '98

15 Oct '98

I would not say that SGCP and IPDC are at all replacing H.323. These protocols are used between a Media Gateway Controller (MC) and a Media Gateway (MG), as device control protocols. An MG is used for telephony to packet conversion, from, for example, PSTN to IP. Interworking with H.323 would occur in the MC and/or the MG. >From what I understand, there is a new work item for developing a device control protocol within SG16. I hope that SGCP and IPDC, and the imminent merging of the two, will be considered as a basis for this protocol. There will be a device control WG set up shortly in the IETF, as well as a mailing list for this subject. I will forward this and the proposed charter for the WG to this mailing list as soon as I receive it. Nancy Friday, October 8/98, Dave Walker wrote: > Dear Mme Lapierre, > > I find it a little confusing that your email says that standards > makers will present what the signalling of VoIP will look like, > and that your agenda refers to the session as an H.323/IP workshop, > yet none of the scheduled talks seem to talk about H.323. Rather > there seems to be a focus on the gateway control protocols (SGCP > and IPDC) which as you know, are being pushed by some parties as > replacements for H.323. Can you clear up my confusion? > > Regards, > > Dave Walker > Mitel Corporation > Ontario, CANADA > > Martine.Lapierre(a)alcatel.fr wrote: > > > > Good evening, > > > > please find attached an invitation to a workshop on VoIP where key > > VoIP experts will be present. > > Standards makers will present what the signalling of VoIP will look > > like, and its impact on the network architecture. > > IP / VoIP manufacturers will be there. > > Operators will be discussing how and when they see VoIP in their > > networks. > > I will be happy to chair this session. > > > > The workshop is sponsored by the TINA consortium, so that the entry > is > > free. > > Nevertheless, we need to know the number of persons who will attend > to > > determine the room size, so be kind enough to register if you or a > > representant of your company are coming. > > > > Martine Lapierre > > > 3 times a year, all telecom operators, telecom manufacturers and IT/IP > manufacturers > > use to meet in the TINA Consortium Technical Forum for a week of > worgroups exchanges, > > Request For Pproposals examinations, including an open workshop. > > > > EURESCOM and the TINA Consortium are pleased to invite you to the > October 98 open > > workshop on H323/IP, that will focus mainly on 2 issues: > > - The re-use of the existing vocal services unto a VoIP network > > - The network architecture and signalling for an IP based vocal and > data operator. > > > > During the afternoon, four presentations and an open discussion will > take place. > > > > AGENDA: > > > > > > Introduction Martine LAPIERRE,TINA-C president > > > > Christian HUITEMA, Bellcore : Controling routers with the SGCP > protocol defined by > > Bellcore and Cisco; the IETSF group; VoIP network architectures > > > > Ike ELLIOT, Level3 and Pete O'CONNELL, Alcatel: Controling VoIP networks > with IPDC; > > associated network architectures > > > > Didier GUY (France Telecom): what could be the future of the telecom > Switches; can TINA > > bring something to VOIP? > > > > William NAVARRO (ETSI/UMTS/TFO Leader, Nortel): introducing VoIP in > mobile networks: > > the Tandem Free Operations signalling, and the IP based UMTS Phase 2 > possible network > > architecture > > > > Question and Answer Session. > > > -------------------------------------------------------------------------- Nancy Greene (internally Nancy-M Greene) Internet & Service Provider Networks, Nortel NOTE NEW #'s: T:514-271-7221 (internally ESN853-1077) E:ngreene@nortel.com -------------------------------------------------------------------------- Nancy Greene (internally Nancy-M Greene) Internet & Service Provider Networks, Nortel NOTE NEW #'s: T:514-271-7221 (internally ESN853-1077) E:ngreene@nortel.com -------------------------------------------------------------------------- Nancy Greene (internally Nancy-M Greene) Internet & Service Provider Networks, Nortel NOTE NEW #'s: T:514-271-7221 (internally ESN853-1077) E:ngreene@nortel.com

1 0

Re: Gk-GK Call signalling - security????
by Sengodan Senthil NRC/Boston 14 Oct '98

14 Oct '98

In the Geneva meeting, it was agreed that the Annex G protocol would be specified in ASN.1, but that the encoding may be one of three possible types (to be decided): 1) templates in BER, with binary wrapper 2) octet strings for templates, binary wrapper 3) octet strings for templates, wrapper in BER I would agree that H.235 needs to be updated once Annex G has reached more stability. In addition to specifically describing the authentication, confidentiality, integrity, non-repudiation and access control mechanisms, I think that the key exchange mechanisms would be very significant in the inter domain scenario. We could either include support for IKE or could include specific features of IKE into the application layer. Regarding whether password based or certificate based mechanisms are more appropriate in an inter-domain scenario, I'd say that they each have their place. In a peering relationship between autonomous systems, a password based mecahnism would suffice - this would be fast and efficient and can be delpoyed easily. But, in the longer term and where no peering relationship exists, a certificate based mechanism may be more appropriate. Issues such as IPSEC or TLS suitability will be clearer depending on when/where UDP/TCP is used within Annex G. - Senthil Senthil Sengodan Nokia Research Center, Boston ---------- From: Euchner Martin To: Jim Toga; Mailing list for parties associ Cc: voip; TIPHON; Klasen Wolfgang Subject: RE: Gk-GK Call signalling - security???? Date: Wednesday, October 14, 1998 10:35AM I agree that H.235 provides already many useful security functions and signaling capabilities that could potentially be used also in annex G. Of course, it has to be described how they could be applied in the new scenario as H.235 does not know about administrative domains and communication among them. Please be aware, that the introduction of this new scenario clearly extends the H.323v2 scope and especially the scope of H.235. You can see this by looking at the high and low priority requirements in annex G. For example, there are requirements saying that border elements can mutually authenticate as well as a foreign GK can authenticate an entity in a different administrative domain. I do not quite see how both issues could be addressed by (present) H.235. The "remote authentication" issues sound challenging; to me; it is not quite clear what 'element' exactly is meant (is it a GK, an endpoint,...)? Another issue is authorization and access control. Present H.235 defines access (authorization) tokens that are useful between endpoints, GK and GW within a zone/administrative domain. Possibly, the mechanism could be extended for annex G purposes. Therefore, it appears to me that annex G requires at least certain "security glue" that describes for example how the authentication within a zone, between administrative domains and authorization fits together. I see also a requirement for non-repudiation services between border elements. H.235 presently does not define explicitly any non-repudiation services. What exactly is the purpose of this non-repudiation? Is it just limited to the border-to-border element communication using annex G protocols is it a more general requirement addressing also other H.323 communication carries across reference point A? Thus, all the listed security requirements seem very important for annex G. Technically, what is less clear to me is what kind of interrelation exists between two administrative domains: Can we assume some sort of passwords to exist between administrative domains such that some sort of "subscription-like" security mechanisms could be applied? Or is an administrative domain rather an isolated environment that does not share certain (long-term) secrets with anybody else? In this case public-key techniques seem more appropriate. My impression on the understanding of the annex G definitions is that an administrative domain very closely resembles a so-called security domain; i.e. a set of administered elements conforming to a certain security policy. Thus, there is a certain level of trust within a domain but not always between domains. A common technology applied today to shield a security domain is using a firewall with network address translation and proxy. Border elements are in the position of an edge device on the security domain perimeter and should offer certain firewall functionality such as protecting the security domain and hiding zone topology information. A first approach shown in annex G is the option that a border element releases only very restricted template information about its zone/domain. Finally, going back to Jan's statement. From following past annex G discussion from the far distance so far, my impression is that most of the discussion has been focussing more on the scope and scenario issues while the protocol details (such as using RAS and/or something else) was not of primary concern. Unfortunately, unless it is clear what signaling protocols are actually used for annex G, it is a bit difficult to progress substantially on the related security issues. martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- > -----Original Message----- > From: Jim Toga [SMTP:jim.toga@intel.com] > Sent: Dienstag, 13. Oktober 1998 19:10 > To: Euchner Martin; Mailing list for parties associated with ITU-T Study > Group 16; ITU-SG16(a)mailbag.cps.intel.com > Cc: voip(a)imtc.org; TIPHON(a)list.etsi.fr; Klasen Wolfgang > Subject: Re: Gk-GK Call signalling - security???? > > Martin, > > I would corroborate Senthil's point. All of the capabilities to utilize > H.235 functionality (including the use of 'external' mechanisms such as > TLS or IPSec) are indended to be available to annex G signaling. > > Some (ok much...) of the procedural description is not included yet. If > anyone sees any specific barriers in accomplishing this, please speak up. > > jimt. > > At 11:50 AM 10/13/98 -0400, Sengodan Senthil NRC/Boston wrote: > >I believe ITU will in fact provide the needed security features for > inter-gatekeeper communication. The determined version of Annex G already > has an authentication field in the zone exchange messages. However, > providing such fields does not guarantee interoperability unless specific > security mechanisms are mandated - which the ITU will probably not get > into. This work - of specifying security profiles for interoperability - > falls within IMTC VoIP and TIPHON. > > > >Regarding Jan's comment, as Gur alluded to, Annex G's immediate focus is > address resolution. Other features, I believe, will be added after this is > tackled. > > > > - Senthil > > > >Senthil Sengodan > >Nokia Research Center, Boston > > ---------- > >From: Euchner Martin > >To: IMTC VoIP reflector; Klasen, Wolfgang; Euchner, Martin > >Subject: RE: Gk-GK Call signalling - security???? > >Date: Tuesday, October 13, 1998 3:11PM > > > >I'm somewhat confused about the statement that Annex G security issues > are > >not in the scope of ITU's work but inTiphon/IMTC. > >>From my impression of the recent ITU-T SG16 meeting in Geneva, the > demand > >for better security regarding the inter-GK scenario was very clearly > >expressed. For obvious reasons, ITU's work on defining enhancements in > annex > >G implies to address also the security issues in an appropriate way. The > >requirements section in annex G lists already several security > requirements, > >so this work item is already part of their work. Of course, there is no > real > >need to invent new security solutions for annex G in case other standards > >bodies have some appropriate technology available that could be > referenced > >for example. > >Whatever security solutions will come out, the result could very smoothly > be > >described and added to the H.235 security recommendation. Note, that > current > >H.235 provides already (some) security solutions to H.225.0; thus, annex > G > >security features seem a natural enhancement to this work. > > > >martin. > > > > ----------------------------------------------------------------------- > >| Dipl.-Inf. Phone: +49 89 636-46201 > >| Martin Euchner Fax : +49 89 636-48000 > >| Siemens AG > >| ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de > >| > >| Otto-Hahn-Ring 6 > >| 81730 Muenchen > >| __________________ > >| Germany > > ----------------------------------------------------------------------- > > > >> -----Original Message----- > >> From: gur kimchi [SMTP:gur.kimchi@ETSI.FR] > >> Sent: Dienstag, 13. Oktober 1998 14:21 > >> To: TIPHON(a)LIST.ETSI.FR > >> Subject: Re: Gk-GK Call signalling - security???? > >> > >> Hi Jan, > >> > >> I attended the Q.13 meeting also - and The scope of Annex G > >> is very well defined: it is attempting to introduce new > >> mechanisms where none exist today. We could argue for hours > >> whether there are inter-gk call-singalling mechanism today, and well, > >> there > >> are (H.225) - the main missing point there is security - which the ITU > >> will not define anyway - but TIPHON (and VoIP). > >> > >> e.g. the new mechanisms are Zone information Exchange. > >> > >> - gur > >> > >> -----Original Message----- > >> From: Ericsson User [mailto:etxjaeh@AL.ETX.ERICSSON.SE] > >> Sent: 13 October 1998 13:40 > >> To: TIPHON > >> Subject: Gk-GK Call signalling > >> > >> > >> Hello All, > >> I participated in the SG 16 meeting in Geneva in september. > >> > >> One thing that suprised me was that the ongoing work with Annex G > (GK-GK > >> signalling) did not consider call control, only the RAS signalling. > >> > >> When I asked why, they did not understand why any change is required. > >> After a while they understood that something could be needed, but it > was > >> postponed to future releases of H.323. > >> > >> Future releases must be version 4 or something (around year 2001 or > >> later ??). > >> > >> The conclusion is then (looking on TIPHON project plan) that H.323 > can't > >> be used between Gatekeepers in TIPHON compliant system. > >> > >> The question is then: What do we use then? ISUP? B-ISUP? SIP? Extended > >> subset of H.323? > >> > >> > >> /Jan Holm > >> Ericsson Telecom AB > >> > >> ------------------------------------------------------------------- > >> ATTENTION !!! TIPHON list distribution parameters have changed: > >> ==> if you REPLY to a TIPHON mail your mail will be sent to the > >> original sender only. > >> ==> if you use REPLY ALL your mail will be sent to TIPHON and > >> to the original sender. > >> ------------------------------------------------------------------- > >> > >> ------------------------------------------------------------------- > >> ATTENTION !!! TIPHON list distribution parameters have changed: > >> ==> if you REPLY to a TIPHON mail your mail will be sent to the > >> original sender only. > >> ==> if you use REPLY ALL your mail will be sent to TIPHON and > >> to the original sender. > >> ------------------------------------------------------------------- > > > > ***************************************************** > *** +1-503-264-8816(voice) Intel - Hillsboro, OR. > *** > *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** > *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** > *****************************************************

1 0

Meeting notice of the November Rapporteur meeting
by Sakae OKUBO 14 Oct '98

14 Oct '98

To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. G. Helder, Vice-Chairman of SG16 Mr. F. Tosco, Chairman of WP2/16 Mr. F. Bigi, ITU-TSB Mr. T. Geary, Rapporteur for Q.11/16 De Sakae OKUBO Rapporteur for Q.12/16 in ITU-T SG16 TAO Waseda Research Center 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 E-mail: okubo(a)giti.or.jp Dale SKRAN Rapporteur for Q.13/16 in ITU-T SG16 Ascend Communications, Inc. 621 Shrewsbury Avenue Shrewsbury, NJ 07702 USA Tel: +1 908 450 1635 Fax: +1 908 450 1611 E-mail: Dale.Skran(a)ascend.com Gary Thom Rapporteur for Q.14/16 in ITU-T SG16 Delta Information Systems Inc. Horsham Business Center Bldg. 3 300 Welsh Road, Horsham, PA 19044 Tel: +1 215 657 5270 ex 23 Fax: +1 215 657 5273 E-mail: gthom(a)delta-info.com ------------------------------------------------ Subject: Notice of Q.12-14/16 Rapporteur Meeting Date: 8 October 1998 ------------------------------------------------ Dear SG16 Colleagues, The subject meeting of ITU-T SG16 experts will be held in Torino, Italy at the kind invitation of CSELT. Please note that Q.11/16 will meet concurrently at the same place and have joint sessions with Q.12-14/16. 1. Date ^^^^^^^ 17 (Tuesday) - 20 (Friday) November 1998 starting at 9:00 on the first day 2. Venue ^^^^^^^^ CSELT Via Reiss Romoli 274 10148 TORINO Italy Tel: +39 011 2285521 Fax: +39 011 2285295 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group meetings 2) Q.12/16 B-ISDN multimedia systems and terminals - White contribution for H.222.0 Amend. 6 - H.321 Implementors Guide - MPEG packetization - Future AV communication system 3) Q.13/16 Packet switched multimedia systems and terminals - Issue white papers for H.450.4/5/6/7, H.323 Annexes E/F/G - Advance the work of H.323 V3/H.225.0 V3 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - Review Recommendations for decision at next SG16 meeting: H.245V5, H.341 (H.MediaMib), H.283 (H.RDC) - Preparation of H.246 Annexes for determination - Discussion of new H.246 interworking Annexes - Discussion of new H.341 Annexes 5) Any other Q.12-14/16 related matters - Interaction with other groups 6) Future work 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 6 November /// /// Distribution of the document: by 10 November /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify S. Okubo as soon as possible, by 6 November (Friday) at the latest. Document number (APC-1nnn) will be allocated. Early indication of your submission plan is welcome. Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16) and Common protocols (Q.14/16) based on coordination with Q.1 ("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document APC-{1nnn}| | Study Group 16 {Version m if relevant}| | Q.12-14/16 Rapporteur Meeting {Date}| | Torino, 17-20 November 1998 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (by 10 November) by posting them at either of the following: - PictureTel ftp site (please advise S. Okubo of your posting) Site: standard.pictel.com/avc-site Login name: anonymous Directory: Incoming - Q.12-14/16 experts reflector e-mail address: itu-sg16(a)mailbag.jf.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /9811_Tor directory of the ftp site. 5) Please bring 60 copies of your document to Torino. Your cooperation is needed to start the meeting with all the documents at hand; please note that the copying capacity at the meeting site is limited. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the attached information from the meeting host. 6. Registration ^^^^^^^^^^^^^^^ Please notify the following person (Mr. Tosco's secretary) of your participation as soon as possible, by 10 November at the latest: Donatella Bertolotti Tel: +39 011 2285521 Fax: +39 011 2285295 E_mail: donatella.bertolotti(a)cselt.it with copy to three Rapporteurs (e-mail: okubo(a)giti.or.jp, Dale.Skran(a)ascend.com, gthom(a)delta-info.com) 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please directly contact a hotel suggested in Mr. Tosco's message as attached. We are looking forward to meeting with you in Torino. Sincerely yours, Sakae OKUBO Dale SKRAN Gary THOM -----<Mr. Tosco's message to Rapporteurs dated 29 September 1998>---- Date: Tue, 29 Sep 1998 17:34:49 +0200 From: Tosco Federico <Federico.Tosco(a)CSELT.IT> Subject: November Expert meeting To: "'Geary, Tom'" <tom.geary(a)nb.rockwell.com>, "'Okubo, Sakae'" <okubo(a)giti.or.jp>, "'Skran, Dale'" <Dale.Skran(a)ascend.com>, "'Thom, Gary'" <gthom(a)delta-info.com> Dear all, First of all I would like to confirm the facilities available for the November meeting: - auditorium (170 seats) - meeting room, 40 places - meeting room, 15-20 places For information about CSELT, how to reach it, hotels in Torino, etc., I suggest you to visit our homepage: http://www.cselt.it. In particular on the presentation page click on "Overview", where you will find: - "Getting to CSELT", where you find information about how to reach CSELT - "A guided tour", where under "Supports" some of the facilities, including the Auditorium, are presented Under "Getting to CSELT" you find also a list of hotels, where you can obtain reduced rates mentioning "CSELT Convention". Torino airport is connected with the main European cities (Paris, Amsterdam, Frankfurt, Brussels, Zurich, Madrid,...) and has many flights to/from Rome every day (see link to Turin Airport under "Getting to CSELT").If you arrive with an intercontinental flight, I suggest to avoid the intercontinental airport of Milano (Milan), which is not far from Torino but has poor connections to Torino. Much better to arrive to Rome or to another destination in Europe having a flight connection to Torino.CSELT is very close to the Torino airport (15 minutes by taxi). ... Best regards Federico CSELT Via Reiss Romoli 274 10148 TORINO Italy Tel.: +39 0112285321 Fax: +39 0112285295 E_mail: federico.tosco(a)cselt.it WARNING! New telephone and fax numbers effective June 19, 1998

2 2

Re: Gk-GK Call signalling - security????
by Euchner Martin 14 Oct '98

14 Oct '98

I agree that H.235 provides already many useful security functions and signaling capabilities that could potentially be used also in annex G. Of course, it has to be described how they could be applied in the new scenario as H.235 does not know about administrative domains and communication among them. Please be aware, that the introduction of this new scenario clearly extends the H.323v2 scope and especially the scope of H.235. You can see this by looking at the high and low priority requirements in annex G. For example, there are requirements saying that border elements can mutually authenticate as well as a foreign GK can authenticate an entity in a different administrative domain. I do not quite see how both issues could be addressed by (present) H.235. The "remote authentication" issues sound challenging; to me; it is not quite clear what 'element' exactly is meant (is it a GK, an endpoint,...)? Another issue is authorization and access control. Present H.235 defines access (authorization) tokens that are useful between endpoints, GK and GW within a zone/administrative domain. Possibly, the mechanism could be extended for annex G purposes. Therefore, it appears to me that annex G requires at least certain "security glue" that describes for example how the authentication within a zone, between administrative domains and authorization fits together. I see also a requirement for non-repudiation services between border elements. H.235 presently does not define explicitly any non-repudiation services. What exactly is the purpose of this non-repudiation? Is it just limited to the border-to-border element communication using annex G protocols is it a more general requirement addressing also other H.323 communication carries across reference point A? Thus, all the listed security requirements seem very important for annex G. Technically, what is less clear to me is what kind of interrelation exists between two administrative domains: Can we assume some sort of passwords to exist between administrative domains such that some sort of "subscription-like" security mechanisms could be applied? Or is an administrative domain rather an isolated environment that does not share certain (long-term) secrets with anybody else? In this case public-key techniques seem more appropriate. My impression on the understanding of the annex G definitions is that an administrative domain very closely resembles a so-called security domain; i.e. a set of administered elements conforming to a certain security policy. Thus, there is a certain level of trust within a domain but not always between domains. A common technology applied today to shield a security domain is using a firewall with network address translation and proxy. Border elements are in the position of an edge device on the security domain perimeter and should offer certain firewall functionality such as protecting the security domain and hiding zone topology information. A first approach shown in annex G is the option that a border element releases only very restricted template information about its zone/domain. Finally, going back to Jan's statement. From following past annex G discussion from the far distance so far, my impression is that most of the discussion has been focussing more on the scope and scenario issues while the protocol details (such as using RAS and/or something else) was not of primary concern. Unfortunately, unless it is clear what signaling protocols are actually used for annex G, it is a bit difficult to progress substantially on the related security issues. martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- > -----Original Message----- > From: Jim Toga [SMTP:jim.toga@intel.com] > Sent: Dienstag, 13. Oktober 1998 19:10 > To: Euchner Martin; Mailing list for parties associated with ITU-T Study > Group 16; ITU-SG16(a)mailbag.cps.intel.com > Cc: voip(a)imtc.org; TIPHON(a)list.etsi.fr; Klasen Wolfgang > Subject: Re: Gk-GK Call signalling - security???? > > Martin, > > I would corroborate Senthil's point. All of the capabilities to utilize > H.235 functionality (including the use of 'external' mechanisms such as > TLS or IPSec) are indended to be available to annex G signaling. > > Some (ok much...) of the procedural description is not included yet. If > anyone sees any specific barriers in accomplishing this, please speak up. > > jimt. > > At 11:50 AM 10/13/98 -0400, Sengodan Senthil NRC/Boston wrote: > >I believe ITU will in fact provide the needed security features for > inter-gatekeeper communication. The determined version of Annex G already > has an authentication field in the zone exchange messages. However, > providing such fields does not guarantee interoperability unless specific > security mechanisms are mandated - which the ITU will probably not get > into. This work - of specifying security profiles for interoperability - > falls within IMTC VoIP and TIPHON. > > > >Regarding Jan's comment, as Gur alluded to, Annex G's immediate focus is > address resolution. Other features, I believe, will be added after this is > tackled. > > > > - Senthil > > > >Senthil Sengodan > >Nokia Research Center, Boston > > ---------- > >From: Euchner Martin > >To: IMTC VoIP reflector; Klasen, Wolfgang; Euchner, Martin > >Subject: RE: Gk-GK Call signalling - security???? > >Date: Tuesday, October 13, 1998 3:11PM > > > >I'm somewhat confused about the statement that Annex G security issues > are > >not in the scope of ITU's work but inTiphon/IMTC. > >>From my impression of the recent ITU-T SG16 meeting in Geneva, the > demand > >for better security regarding the inter-GK scenario was very clearly > >expressed. For obvious reasons, ITU's work on defining enhancements in > annex > >G implies to address also the security issues in an appropriate way. The > >requirements section in annex G lists already several security > requirements, > >so this work item is already part of their work. Of course, there is no > real > >need to invent new security solutions for annex G in case other standards > >bodies have some appropriate technology available that could be > referenced > >for example. > >Whatever security solutions will come out, the result could very smoothly > be > >described and added to the H.235 security recommendation. Note, that > current > >H.235 provides already (some) security solutions to H.225.0; thus, annex > G > >security features seem a natural enhancement to this work. > > > >martin. > > > > ----------------------------------------------------------------------- > >| Dipl.-Inf. Phone: +49 89 636-46201 > >| Martin Euchner Fax : +49 89 636-48000 > >| Siemens AG > >| ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de > >| > >| Otto-Hahn-Ring 6 > >| 81730 Muenchen > >| __________________ > >| Germany > > ----------------------------------------------------------------------- > > > >> -----Original Message----- > >> From: gur kimchi [SMTP:gur.kimchi@ETSI.FR] > >> Sent: Dienstag, 13. Oktober 1998 14:21 > >> To: TIPHON(a)LIST.ETSI.FR > >> Subject: Re: Gk-GK Call signalling - security???? > >> > >> Hi Jan, > >> > >> I attended the Q.13 meeting also - and The scope of Annex G > >> is very well defined: it is attempting to introduce new > >> mechanisms where none exist today. We could argue for hours > >> whether there are inter-gk call-singalling mechanism today, and well, > >> there > >> are (H.225) - the main missing point there is security - which the ITU > >> will not define anyway - but TIPHON (and VoIP). > >> > >> e.g. the new mechanisms are Zone information Exchange. > >> > >> - gur > >> > >> -----Original Message----- > >> From: Ericsson User [mailto:etxjaeh@AL.ETX.ERICSSON.SE] > >> Sent: 13 October 1998 13:40 > >> To: TIPHON > >> Subject: Gk-GK Call signalling > >> > >> > >> Hello All, > >> I participated in the SG 16 meeting in Geneva in september. > >> > >> One thing that suprised me was that the ongoing work with Annex G > (GK-GK > >> signalling) did not consider call control, only the RAS signalling. > >> > >> When I asked why, they did not understand why any change is required. > >> After a while they understood that something could be needed, but it > was > >> postponed to future releases of H.323. > >> > >> Future releases must be version 4 or something (around year 2001 or > >> later ??). > >> > >> The conclusion is then (looking on TIPHON project plan) that H.323 > can't > >> be used between Gatekeepers in TIPHON compliant system. > >> > >> The question is then: What do we use then? ISUP? B-ISUP? SIP? Extended > >> subset of H.323? > >> > >> > >> /Jan Holm > >> Ericsson Telecom AB > >> > >> ------------------------------------------------------------------- > >> ATTENTION !!! TIPHON list distribution parameters have changed: > >> ==> if you REPLY to a TIPHON mail your mail will be sent to the > >> original sender only. > >> ==> if you use REPLY ALL your mail will be sent to TIPHON and > >> to the original sender. > >> ------------------------------------------------------------------- > >> > >> ------------------------------------------------------------------- > >> ATTENTION !!! TIPHON list distribution parameters have changed: > >> ==> if you REPLY to a TIPHON mail your mail will be sent to the > >> original sender only. > >> ==> if you use REPLY ALL your mail will be sent to TIPHON and > >> to the original sender. > >> ------------------------------------------------------------------- > > > > ***************************************************** > *** +1-503-264-8816(voice) Intel - Hillsboro, OR. > *** > *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** > *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** > *****************************************************

1 0

RE: Gk-GK Call signalling - security????
by sengodan＠NASBPD01BS.ntc.nokia.com 13 Oct '98

13 Oct '98

I believe ITU will in fact provide the needed security features for inter-gatekeeper communication. The determined version of Annex G already has an authentication field in the zone exchange messages. However, providing such fields does not guarantee interoperability unless specific security mechanisms are mandated - which the ITU will probably not get into. This work - of specifying security profiles for interoperability - falls within IMTC VoIP and TIPHON. Regarding Jan's comment, as Gur alluded to, Annex G's immediate focus is address resolution. Other features, I believe, will be added after this is tackled. - Senthil Senthil Sengodan Nokia Research Center, Boston ---------- From: Euchner Martin To: IMTC VoIP reflector; Klasen, Wolfgang; Euchner, Martin Subject: RE: Gk-GK Call signalling - security???? Date: Tuesday, October 13, 1998 3:11PM I'm somewhat confused about the statement that Annex G security issues are not in the scope of ITU's work but inTiphon/IMTC. >From my impression of the recent ITU-T SG16 meeting in Geneva, the demand for better security regarding the inter-GK scenario was very clearly expressed. For obvious reasons, ITU's work on defining enhancements in annex G implies to address also the security issues in an appropriate way. The requirements section in annex G lists already several security requirements, so this work item is already part of their work. Of course, there is no real need to invent new security solutions for annex G in case other standards bodies have some appropriate technology available that could be referenced for example. Whatever security solutions will come out, the result could very smoothly be described and added to the H.235 security recommendation. Note, that current H.235 provides already (some) security solutions to H.225.0; thus, annex G security features seem a natural enhancement to this work. martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- > -----Original Message----- > From: gur kimchi [SMTP:gur.kimchi@ETSI.FR] > Sent: Dienstag, 13. Oktober 1998 14:21 > To: TIPHON(a)LIST.ETSI.FR > Subject: Re: Gk-GK Call signalling - security???? > > Hi Jan, > > I attended the Q.13 meeting also - and The scope of Annex G > is very well defined: it is attempting to introduce new > mechanisms where none exist today. We could argue for hours > whether there are inter-gk call-singalling mechanism today, and well, > there > are (H.225) - the main missing point there is security - which the ITU > will not define anyway - but TIPHON (and VoIP). > > e.g. the new mechanisms are Zone information Exchange. > > - gur > > -----Original Message----- > From: Ericsson User [mailto:etxjaeh@AL.ETX.ERICSSON.SE] > Sent: 13 October 1998 13:40 > To: TIPHON > Subject: Gk-GK Call signalling > > > Hello All, > I participated in the SG 16 meeting in Geneva in september. > > One thing that suprised me was that the ongoing work with Annex G (GK-GK > signalling) did not consider call control, only the RAS signalling. > > When I asked why, they did not understand why any change is required. > After a while they understood that something could be needed, but it was > postponed to future releases of H.323. > > Future releases must be version 4 or something (around year 2001 or > later ??). > > The conclusion is then (looking on TIPHON project plan) that H.323 can't > be used between Gatekeepers in TIPHON compliant system. > > The question is then: What do we use then? ISUP? B-ISUP? SIP? Extended > subset of H.323? > > > /Jan Holm > Ericsson Telecom AB > > ------------------------------------------------------------------- > ATTENTION !!! TIPHON list distribution parameters have changed: > ==> if you REPLY to a TIPHON mail your mail will be sent to the > original sender only. > ==> if you use REPLY ALL your mail will be sent to TIPHON and > to the original sender. > ------------------------------------------------------------------- > > ------------------------------------------------------------------- > ATTENTION !!! TIPHON list distribution parameters have changed: > ==> if you REPLY to a TIPHON mail your mail will be sent to the > original sender only. > ==> if you use REPLY ALL your mail will be sent to TIPHON and > to the original sender. > -------------------------------------------------------------------

2 1

Re: Gk-GK Call signalling
by Jim Toga 13 Oct '98

13 Oct '98

Jan, Being one of the contributors of some of the text.... There was no intent to limit GK-GK communications to RAS or Call Control. The plan of attack was to initially solve some specific issues with being able to complete Inter-zone calls. The fact that the messages are carried in RAS format was simply a straw-man proposal. The content and logic was the important starting point. As is always the case, this work moves forward with contributions. What specific functions do you want to acomplish? It might help me (and others) to understand where the specific holes are, in order to figure out what the next holes are (in the IP context) rather simply saying we need to port ISUP to GKs. Best Regards, jimt. At 01:39 PM 10/13/98 +0100, Ericsson User wrote: >Hello All, >I participated in the SG 16 meeting in Geneva in september. > >One thing that suprised me was that the ongoing work with Annex G (GK-GK >signalling) did not consider call control, only the RAS signalling. > >When I asked why, they did not understand why any change is required. >After a while they understood that something could be needed, but it was >postponed to future releases of H.323. > >Future releases must be version 4 or something (around year 2001 or >later ??). > >The conclusion is then (looking on TIPHON project plan) that H.323 can't >be used between Gatekeepers in TIPHON compliant system. > >The question is then: What do we use then? ISUP? B-ISUP? SIP? Extended >subset of H.323? > > >/Jan Holm >Ericsson Telecom AB > >------------------------------------------------------------------- >ATTENTION !!! TIPHON list distribution parameters have changed: >==> if you REPLY to a TIPHON mail your mail will be sent to the >original sender only. >==> if you use REPLY ALL your mail will be sent to TIPHON and >to the original sender. >------------------------------------------------------------------- > ***************************************************** *** +1-503-264-8816(voice) Intel - Hillsboro, OR. *** *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** *****************************************************

1 0

Use of alias address and transport address in H.225.0
by Ernst Horvath 12 Oct '98

12 Oct '98

Hi, Can anybody answer the following questions regarding the use of addresses in H.225.0: 1) Type TransportAddress: What is the purpose of alternative 'ipSourceRoute', is it currently used for anything? 2) Type AliasAddress: What is the purpose of alternative 'transportAddress'? Must this be an address of the underlying network (usually IP), or can it be a different type (for example, an NSAP address)? Reason behind question 2): When interworking with an ATM network which implements ATM-Forum protocols, the ATM terminal's address may be in NSAP format. Type AliasAddress in H.225.0 has no 'nsap' alternative, but type TransportAddress has. Could NSAP addresses now be included in AliasAddress via alternative 'transportAddress'? Ernst Horvath Siemens AG Email: ernst.horvath(a)siemens.at

1 0

R:Mr. Tosco report of WP2/16
by Tosco Federico 12 Oct '98

12 Oct '98

Dear Mr. Okubo, Thank you for having made available the WP2/16 report. Best regards Federico Tosco > ---------- > Da: Sakae OKUBO[SMTP:okubo@GITI.OR.JP] > Risposta a: Mailing list for parties associated with ITU-T Study Group > 16 > Inviato: lunedì 5 ottobre 1998 11.08 > A: ITU-SG16(a)mailbag.cps.intel.com > Oggetto: Mr. Tosco report of WP2/16 > > Dear Q.12-14/16 experts, > > Please be advised that Mr. Tosco's report of WP2/16 of the September SG16 > meeting has been placed at the following: > > ftp://standard.pictel.com/avc-site/9809_Gen/Tosco_WP2_report.zip > > Best regards, > > Sakae OKUBO (Mr.) > *********************************************************** > Waseda Research Center > Telecommunications Advancement Organization of Japan (TAO) > 5th Floor, Nishi-Waseda Bldg. > 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo > 169-0051 Japan > Tel: +81 3 5286 3830 > Fax: +81 3 5287 7287 > e-mail: okubo(a)giti.or.jp > *********************************************************** >

1 0

Re: I invite you to an important session on Voice over IP
by Dave Walker 09 Oct '98

09 Oct '98

Dear Mme Lapierre, I find it a little confusing that your email says that standards makers will present what the signalling of VoIP will look like, and that your agenda refers to the session as an H.323/IP workshop, yet none of the scheduled talks seem to talk about H.323. Rather there seems to be a focus on the gateway control protocols (SGCP and IPDC) which as you know, are being pushed by some parties as replacements for H.323. Can you clear up my confusion? Regards, Dave Walker Mitel Corporation Ontario, CANADA Martine.Lapierre(a)alcatel.fr wrote: > > Good evening, > > please find attached an invitation to a workshop on VoIP where key > VoIP experts will be present. > Standards makers will present what the signalling of VoIP will look > like, and its impact on the network architecture. > IP / VoIP manufacturers will be there. > Operators will be discussing how and when they see VoIP in their > networks. > I will be happy to chair this session. > > The workshop is sponsored by the TINA consortium, so that the entry is > free. > Nevertheless, we need to know the number of persons who will attend to > determine the room size, so be kind enough to register if you or a > representant of your company are coming. > > Martine Lapierre > 3 times a year, all telecom operators, telecom manufacturers and IT/IP manufacturers > use to meet in the TINA Consortium Technical Forum for a week of worgroups exchanges, > Request For Pproposals examinations, including an open workshop. > > EURESCOM and the TINA Consortium are pleased to invite you to the October 98 open > workshop on H323/IP, that will focus mainly on 2 issues: > - The re-use of the existing vocal services unto a VoIP network > - The network architecture and signalling for an IP based vocal and data operator. > > During the afternoon, four presentations and an open discussion will take place. > > AGENDA: > > > Introduction Martine LAPIERRE,TINA-C president > > Christian HUITEMA, Bellcore : Controling routers with the SGCP protocol defined by > Bellcore and Cisco; the IETSF group; VoIP network architectures > > Ike ELLIOT, Level3 and Pete OCONNELL, Alcatel: Controling VoIP networks with IPDC; > associated network architectures > > Didier GUY (France Telecom): what could be the future of the telecom Switches; can TINA > bring something to VOIP? > > William NAVARRO (ETSI/UMTS/TFO Leader, Nortel): introducing VoIP in mobile networks: > the Tandem Free Operations signalling, and the IP based UMTS Phase 2 possible network > architecture > > Question and Answer Session. >

1 0