- sg16-avd - lists.packetizer.com

Re: Alcatel Reaction on H.323m contributions
by Laurent Thiebaut 15 Nov '99

15 Nov '99

Hello everybody, I have just subscribe to itu-sg16. I'm mostly interested in H.323 link with radio access, being involved in 3GPP standardization (3GPP S2 working group responsible of network architecture) Please find attached some comments on Contribution "Integrating 3GPP's option-1 architecture into the H.323 wireless IP mobility system and a full migration from GPRS to a Multimedia IP network proposal" (file MTD-05) - source Motorola - to be … [View More]discussed on wednesday about H323 mobility. - comment on section "Alternate Proposal for an all IP option for 3GPP R'00. The purpose the all IP proposal is also to allow support of release 99 CS domain terminals. In addition it will also support the IP based services of option 1." The figure shown in the contribution does **NOT** correspond to the support of the CS terminals as described in 3GPP 23.922. This option 2 of the 3GPP standard corresponds to the option 1 architecture plus -- a MSC server mainly that comprises the call control and mobility control parts of a GSM/UMTS R99 MSC. MSC server controls the parts of the call state that pertain to connection control for media channels in a MGW. -- A GMSC server that mainly comprises the call control and mobility control parts of a GSM/UMTS R99 GMSC. The attached MTD05comment.zip contains extracts from 3GPP23.922 that explain the 3GPP position on network architecture. The following further discrepancies between contribution MTD05 and 3GPP specifications are: -- The network architecture defined by 3GPP does *NOT* imply to have the GK and the SGSN function mixed, -- nor has 3GPP accepted to merge the GGSN and the MG functions -- nor has 3GPP accepted to have a Gi interface between UTRAN (radio) and GGSN (Gateway to Packet Data networks such as Intranets / ISPs). Merging of functions is always possible at the implementation level but should not be dictated by standardization when not necessary. As H.323 networks may have to interact with other non 3GPP radio (and even mobile, non terrestrial radio) networks, it is better to have, as 3GPP has done, a clear separation between (radio) access bearer layer - UTRAN, ERAN, SGSN, GGSN for 3GPP networks, PDSN for CDMA2000 networks - and multimedia call control layer e.g. GK. Best regards Laurent T. --------------------------------------------------------------------------- V Laurent Thiebaut tel: +33 (0)1 3077 0645 A L C A T E L e.mail:laurent.thiebaut@alcatel.fr --------------------------------------------------------------------------- (Alcatel representant to 3GPP SA Working group 2 that is responsible of 3GPP system architecture) [View Less]

1 0

Re: H.323 mobility:MTD number request
by Anders Svennevik (ERA) 15 Nov '99

15 Nov '99

Hi, Could I have an MTD number? The title of the document will most likely be something along the lines of "Defintion of terms for H.323 Annex H". Anders Svennevik Ericsson Radio

1 0

Re: [Robustness] Telecon scheduled for Tuesday, 11/16 at 11AM EST USA
by Roy, Radhika R, ALARC 12 Nov '99

12 Nov '99

Hi, Maureen and All: In addition to TD-28, I am also adding a part of APC-1748b (Q.13 Rap.'s meeting report of Red bank meeting): "..It was noted that D.225 from Chile is relevant..." D.225 was not reflected in TD-28. Emails were also sent to clarify this. For completeness of this email, I am adding this as well. We will discuss this in the conference call when we discuss the terms of reference per TD-28. Thanks to Maureen for arranging the conf. call. Best regards, Radhika R. Roy AT&T … [View More]

1 0

[Robustness] Telecon scheduled for Tuesday, 11/16 at 11AM EST USA
by Maureen Stillman 12 Nov '99

12 Nov '99

This is a reminder that we will be having the first teleconference on robustness sponsored by Nokia on Tuesday, November 16 at 11AM EST USA. The phone number to call is: 613-688-2795 and the access code is 1097#. You must enter the pound key after the access code. The tentative agenda is: Definitions of Terms for robustness Items that can be settled in the short term Attached for your information are the terms of reference (TD-28) agreed upon at the last Study Group 16 meeting in Red … [View More]

1 0

Re: H.323 mobility:MTD number request
by Reddy, Paul K 12 Nov '99

12 Nov '99

Hi Jaakko, I have assigned the following MTD number for your document: MTD-06: Title: H.323 Functional Architecture and Reference Points. Company: Nokia Regards, -Paul Paul K. Reddy Intel Architecture Labs, Intel Corporation, 2111 NE 25th Avenue, Hillsboro, OR - 97124, USA, Office Phone# +1 (503)-264-9896 -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Friday, November 12, 1999 12:30 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H.323 mobility:… [View More]

1 0

Re: H323 mobility: Summary of discussion
by Roy, Radhika R, ALARC 12 Nov '99

12 Nov '99

Hi, Gösta and All: Everyone is welcomed to join discussion and bring contributions to make their point of view clearer. Anyone can bring contributions anytime no matter what the state of the document submitted by the editor is unless the standard is decided. Discussion are progressed based on contributions. Only contributions provide a basis for discussion. In the last Red Bank meeting, we had an wonderful opportunity to understand each other's points based on contributions. We have made … [View More]good progress compared to that of the Berlin meeting. Definitely we need the help from the people like you and all others to have a common understanding. We expect to hear more from you in the upcoming conference call. Our final goal is to find a solution!!! Best regards, Radhika R. Roy > -----Original Message----- > From: Gösta Linder (LME) [SMTP:Gosta.Linder@LME.ERICSSON.SE] > Sent: Friday, November 12, 1999 3:36 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323 mobility: Summary of discussion > > The discussion carried in this mails strengthen the need for some agreed > scope and model for what we mean with Mobility Management to support Multi > Media/H323 communication. This type of process to proceed was agreed in > Red Bank and that is what I hope all will agree upon as a basis for Nov 17 > teleconf meeting. TD 16 was our first attemt to come to a tighter > definition before we go into discussion of solutions. Discussion of > solutions would not be fruitful as long as we do not have a common > understanding of the problem /service to be resolved and within which > network environment the service should be introduced. > /Gösta Linder > > -----Original Message----- > From: Adam Li [mailto:adamli@ICSL.UCLA.EDU] > Sent: den 10 november 1999 10:41 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: H323 mobility: Summary of discussion > > > Hi, all, > > Barry Aronson's comment seems to make a lot of sense to me. > > I am new to the H.323 group, but I've been reading the email > correspondences here for quite a while. May I ask a few dumb > questions, and please correct me and elighten me if I am wrong? > > Question: Consider the wireless case, isn't that H.323M is > going to be used over some wireless network (e.g. 3G IMT2000 > network)? If such network is already built to ensure that your > data gets transmitted to you no matter you walk or drive from > one zone to the other, why can't our H.323M terminal just > sit at the handset and wait for our data get routed to us > by the network? Or, why do we need to duplicate these > functions that are already provided, and should be provided > by the network layer? > > Maybe, all we have to do is to make sure we know the data is from > the same entity when it changes its attaching point, since each > H.323 entity is identified by the LAN address (H.323 7.1.1). > A simple extension of assigning a temporary ID number to each > entity or to each conference can solve that. > > Please enlighten if there is any special compelling reason that > I might have overlooked for duplicating an entire mobile network > functionality within H.323. Thanks in advance. > > Adam Li > > > Edgar Martinez [1] writes: > > > > Comments: follow-- > > > > Barry Aronson wrote: > > > > > All, > > > > > > I agree with Tom. We seem to be headed for designing an entire mobile > > > network within H.323 -- definitely a case of the tail wagging the dog. > If > > > this was the desire, extending existing mobile networks (AMPS, GSM, > etc.) to > > > include H.323 terminals would be simpler. > > > > This is called the WAP solution, already done but it is still > > two separate networks (MSC-CS and PDN) routed/ split out > > by a DSU from the BSC. And it does not address the fixed > > Internet PC or any PSTN/ISDN interworking. > > > > > That is, of course, unless you > > > wanted the terminals to be independent of the physical network from > the > > > network layer on up. H.323 could do this if there was an underlying > packet > > > based network -- probably IP. Using IP as a common network layer for > both > > > wireless and wired terminals is of course all the rage these days. > Given > > > that universal wireless terminals are been worked as part of IMT-2000 > (and > > > 3GPP, 3GPP-2, etc.), wouldn't it make sense to define the Annex H > issues > > > being debated in the appropriate network groups? > > > > We are looking at the H.323 mobility at the appilation layer within > > the approriate woking groups. > > > > > > > > > > > > > Maybe I misunderstood, but I thought in Santiago the purpose of Annex > H and > > > I was to make H.323 work within the context of a mobile terminal > and/or > > > user, and also allow for service mobility. > > > > I feel a mobile IP debate is in the starts here but, We are looking at > > the H.323 mobility at the appilation layer within the approriate woking > > group. > > > > What the IETF needs to address is how mobile IP interworks with Mobility > > whether is H.323, GSM, PLNM or otherwise.. > > > > > I don't think any of what is > > > being discussed for Annex H is necessary to achieve this. > > > > What being discussed here is, we are looking at > > the H.323 mobility from the appilation layer. > > > > > > > > > > > Barry > > > > > > -----Original Message----- > > > From: Mailing list for parties associated with ITU-T Study Group 16 > > > [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Tom-PT Taylor > > > Sent: Friday, November 05, 1999 11:17 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: H323 mobility: Summary of discussion > > > > > > I think a basic point in this discussion is that mobility is "bigger > than" > > > H.323 and already has well-established architectural underpinnings. > It's > > > all very well to talk about an H.323 solution which we could then > adapt, but > > > we would more likely end up with an H.323-only solution as a result. > The > > > concern then would be whether vendors saw sufficient opportunity in > building > > > to this market, compared with the general market for mobility > products. > > > > -- > > Edgar Martinez - Principal Staff Engineer > > Email mailto:martinze@cig.mot.com > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > > > > -- > Adam H. Li > Image Process Lab > University of California - Los Angeles > (Phone) 310-825-5178 (Fax) 310-825-7928 [View Less]

1 0

Re: H323 mobility: Summary of discussion
by Gösta Linder (LME) 12 Nov '99

12 Nov '99

The discussion carried in this mails strengthen the need for some agreed scope and model for what we mean with Mobility Management to support Multi Media/H323 communication. This type of process to proceed was agreed in Red Bank and that is what I hope all will agree upon as a basis for Nov 17 teleconf meeting. TD 16 was our first attemt to come to a tighter definition before we go into discussion of solutions. Discussion of solutions would not be fruitful as long as we do not have a common … [View More]understanding of the problem /service to be resolved and within which network environment the service should be introduced. /Gösta Linder -----Original Message----- From: Adam Li [mailto:adamli@ICSL.UCLA.EDU] Sent: den 10 november 1999 10:41 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H323 mobility: Summary of discussion Hi, all, Barry Aronson's comment seems to make a lot of sense to me. I am new to the H.323 group, but I've been reading the email correspondences here for quite a while. May I ask a few dumb questions, and please correct me and elighten me if I am wrong? Question: Consider the wireless case, isn't that H.323M is going to be used over some wireless network (e.g. 3G IMT2000 network)? If such network is already built to ensure that your data gets transmitted to you no matter you walk or drive from one zone to the other, why can't our H.323M terminal just sit at the handset and wait for our data get routed to us by the network? Or, why do we need to duplicate these functions that are already provided, and should be provided by the network layer? Maybe, all we have to do is to make sure we know the data is from the same entity when it changes its attaching point, since each H.323 entity is identified by the LAN address (H.323 7.1.1). A simple extension of assigning a temporary ID number to each entity or to each conference can solve that. Please enlighten if there is any special compelling reason that I might have overlooked for duplicating an entire mobile network functionality within H.323. Thanks in advance. Adam Li Edgar Martinez [1] writes: > > Comments: follow-- > > Barry Aronson wrote: > > > All, > > > > I agree with Tom. We seem to be headed for designing an entire mobile > > network within H.323 -- definitely a case of the tail wagging the dog. If > > this was the desire, extending existing mobile networks (AMPS, GSM, etc.) to > > include H.323 terminals would be simpler. > > This is called the WAP solution, already done but it is still > two separate networks (MSC-CS and PDN) routed/ split out > by a DSU from the BSC. And it does not address the fixed > Internet PC or any PSTN/ISDN interworking. > > > That is, of course, unless you > > wanted the terminals to be independent of the physical network from the > > network layer on up. H.323 could do this if there was an underlying packet > > based network -- probably IP. Using IP as a common network layer for both > > wireless and wired terminals is of course all the rage these days. Given > > that universal wireless terminals are been worked as part of IMT-2000 (and > > 3GPP, 3GPP-2, etc.), wouldn't it make sense to define the Annex H issues > > being debated in the appropriate network groups? > > We are looking at the H.323 mobility at the appilation layer within > the approriate woking groups. > > > > > > > > Maybe I misunderstood, but I thought in Santiago the purpose of Annex H and > > I was to make H.323 work within the context of a mobile terminal and/or > > user, and also allow for service mobility. > > I feel a mobile IP debate is in the starts here but, We are looking at > the H.323 mobility at the appilation layer within the approriate woking > group. > > What the IETF needs to address is how mobile IP interworks with Mobility > whether is H.323, GSM, PLNM or otherwise.. > > > I don't think any of what is > > being discussed for Annex H is necessary to achieve this. > > What being discussed here is, we are looking at > the H.323 mobility from the appilation layer. > > > > > > > Barry > > > > -----Original Message----- > > From: Mailing list for parties associated with ITU-T Study Group 16 > > [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Tom-PT Taylor > > Sent: Friday, November 05, 1999 11:17 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: H323 mobility: Summary of discussion > > > > I think a basic point in this discussion is that mobility is "bigger than" > > H.323 and already has well-established architectural underpinnings. It's > > all very well to talk about an H.323 solution which we could then adapt, but > > we would more likely end up with an H.323-only solution as a result. The > > concern then would be whether vendors saw sufficient opportunity in building > > to this market, compared with the general market for mobility products. > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > -- Adam H. Li Image Process Lab University of California - Los Angeles (Phone) 310-825-5178 (Fax) 310-825-7928 [View Less]

1 0

H.323 mobility:MTD number request
by Jaakko Sundquist 12 Nov '99

12 Nov '99

Hi Paul, Could you reserve an MTD number for Nokia. The title of the document will be something along the lines: H.323 Functional Architecture and Reference Points. - Jaakko Sundquist ------------------------------------------------------- In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort. -------------------------------------------------------

1 0

Re: H.323 mobility:Reserve TDs
by Reddy, Paul K 11 Nov '99

11 Nov '99

Hi Radhika, Yes, I am assigning the MTD-xx numbers for the all the contributions submitted to be discussed during our conference call. -Paul Paul K. Reddy Intel Architecture Labs, Intel Corporation, 2111 NE 25th Avenue, Hillsboro, OR - 97124, USA, Office Phone# +1 (503)-264-9896 -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Thursday, November 11, 1999 5:57 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 mobility:Reserve TDs Hi, Ed and Paul: … [View More]

1 0

Re: H.323 mobility:Reserve TDs
by Reddy, Paul K 11 Nov '99

11 Nov '99

Dear Edgar, I have assigned the Mobile Temporary Document numbers as you requested to 3 documents, which are submitted towards conference call discussion on November 17, 1999. MTD-03: Title: H.323 Annex-H Draft and outline Company: Motorola MTD-04: Title: The Level 1 headings for H.323 Annex-H interworking with legacy mobile networks and mobile terminals (from the IP network perspective). Company: Motorola MTD-05: Title: Informational only) Full migration from GPRS to a Multimedia IP … [View More]

1 0

H.323 Mobilty: Downloaded MTD 03-05
by Edgar Martinez [1] 11 Nov '99

11 Nov '99

Dear Mobility Team, Not to overload SG16 mailer with comments as contributions start to come in. I will like to suggest that we restrain from any comments to the MTD's until we have the conference call and are given opportunely to explain the MTD. Contributions MTD-03, 04, 05 have been loaded to ftp://standard.pictel.com/avc-site/Incoming MTD-03 will be H.323 Annex-H Darft and outline. > > > > MTD-04 will be the Level 1 headings for H.323 Annex-H interworking with legcay mobile … [View More]

1 0

Re: H.323 mobility: Reserve TDs
by Edgar Martinez [1] 11 Nov '99

11 Nov '99

Great, We do not to have maintain a separate directory for mobility. I will then download my MTD's to the regular Incoming. ftp://standard.pictel.com/avc-site/Incoming Thanks, Ed "Roy, Radhika R, ALARC" wrote: > Hi, Ed: > > We did not hear any objection after your suggestion. Now we are assuming > that it is OK to use MTD.xxx for our mobility work. > > Best regards, > Radhika > > > -----Original Message----- > > From: Edgar Martinez [1] [SMTP:martinze@… [View More]CIG.MOT.COM] > > Sent: Thursday, November 11, 1999 8:54 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: H.323 mobility:Reserve TDs > > > > Hi Radhika, > > > > I suggested it, if it is OK by everyone I prefer > > MTD.xxx it will also help to keep track of the > > Mobility TD's without having to open the other > > regular TD's to look for the subject. > > > > Regards, > > Ed > > > > "Roy, Radhika R, ALARC" wrote: > > > > > Hi, Ed and Paul: > > > > > > Did we not agree that we will provide "MTD.xxx" instead of "TD.xxx" to > > > differentiate from the regular "TD.xxx"? > > > > > > Thanks, > > > Radhika > > > > > > > -----Original Message----- > > > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > > > Sent: Wednesday, November 10, 1999 10:37 PM > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > > Subject: H.323 mobility:Reserve TDs > > > > > > > > Paul, > > > > > > > > I will like to reserve the following TDs. TD 03, 04 and 05. > > > > For the h.332 mobility Ad-hoc meeting. > > > > > > > > TD-03 will be H.323 Annex-H Darft and outline. > > > > > > > > TD-04 will be the Level 1 headings for H.323 Annex-H > > > > interworking with legcay mobile networks and mobile > > > > terminals (from the IP network perspective). > > > > > > > > TD-05 (Informational only) Full migration from GPRS > > > > to a Multimedia IP network (from the H.323 IP network > > > > perspective). > > > > > > > > Thank you, > > > > -- > > > > Edgar Martinez - Principal Staff Engineer > > > > Email mailto:martinze@cig.mot.com > > > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > > > -- > > Edgar Martinez - Principal Staff Engineer > > Email mailto:martinze@cig.mot.com > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ [View Less]

1 0

Re: H.323 mobility: Reserve TDs
by Roy, Radhika R, ALARC 11 Nov '99

11 Nov '99

Hi, Ed: We did not hear any objection after your suggestion. Now we are assuming that it is OK to use MTD.xxx for our mobility work. Best regards, Radhika > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Thursday, November 11, 1999 8:54 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 mobility:Reserve TDs > > Hi Radhika, > > I suggested it, if it is OK by everyone I prefer > MTD.xxx it will also help to … [View More]

1 0

Re: H.323 mobility:Reserve TDs
by Roy, Radhika R, ALARC 11 Nov '99

11 Nov '99

Hi, Ed and Paul: Did we not agree that we will provide "MTD.xxx" instead of "TD.xxx" to differentiate from the regular "TD.xxx"? Thanks, Radhika > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Wednesday, November 10, 1999 10:37 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323 mobility:Reserve TDs > > Paul, > > I will like to reserve the following TDs. TD 03, 04 and 05. > For the h.332 mobility Ad-hoc … [View More]

1 0

Re: H.323 mobility:Reserve TDs
by Edgar Martinez [1] 11 Nov '99

11 Nov '99

Hi Radhika, I suggested it, if it is OK by everyone I prefer MTD.xxx it will also help to keep track of the Mobility TD's without having to open the other regular TD's to look for the subject. Regards, Ed "Roy, Radhika R, ALARC" wrote: > Hi, Ed and Paul: > > Did we not agree that we will provide "MTD.xxx" instead of "TD.xxx" to > differentiate from the regular "TD.xxx"? > > Thanks, > Radhika > > > -----Original Message----- > > From: Edgar Martinez [1] [… [View More]

1 0

H.450.3 interrogation procedure
by Henri M�enp�� 11 Nov '99

11 Nov '99

All, I have a question concerning H.450.3 Call Diversion supplementary service, and more specifically about the interrogation procedure. The response to an interrogation of current activations consists of a list of IntResult IEs. Each of these describe one diversion activation "description". Among the information fields is this boolean value remoteEnabled. What is the purpose of this? -Henri Mäenpää

1 0

H.245 address and tunneling
by El-Gebaly, Hani 11 Nov '99

11 Nov '99

Greetings all, I have a question regarding tunneling and H.245 address. Suppose a terminal returned a connect message with a valid H.245 address (IP+port) together with tunneling set to TRUE. What should be the behavior of the receiving terminal in this case? It can be either: 1. The terminal establishes a separate H.245 TCP connection and starts H.245 procedure. 2. The terminal ignores the H.245 … [View More]

2 1

Final version of the Red Bank meeting report APC-1748
by Sakae OKUBO 10 Nov '99

10 Nov '99

Dear Q12-14/16 experts, I have placed the Red Bank meeting report with confirmed status at the PictureTel ftp site: ftp://standard.pictel.com/avc-site/9910_Red/APC-1748b.zip or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1748b.zip The following elaboration has been made from the previous version APC-1748a for your confirmation: 1) At the end of Section 5.4.1.2 "Related to Transport of QSIG & ISUP in H.323 systems", a sentence has been added in response to Mr. Potter's comment.… [View More]

1 0

H.323 mobility:Reserve TDs
by Edgar Martinez [1] 10 Nov '99

10 Nov '99

Paul, I will like to reserve the following TDs. TD 03, 04 and 05. For the h.332 mobility Ad-hoc meeting. TD-03 will be H.323 Annex-H Darft and outline. TD-04 will be the Level 1 headings for H.323 Annex-H interworking with legcay mobile networks and mobile terminals (from the IP network perspective). TD-05 (Informational only) Full migration from GPRS to a Multimedia IP network (from the H.323 IP network perspective). Thank you, -- Edgar Martinez - Principal Staff Engineer Email mailto:… [View More]

1 0

Re: LogicalChannelRate Messages
by El-Gebaly, Hani 10 Nov '99

10 Nov '99

Aseem, Paul and all, LogicalChanelRate SDL should be very similar to any request/response pair like Paul mentioned. This was an Intel contribution for controlling video/data channel bitrate. I will consider bringing a clarification contribution to version 6 maybe and the implementers guide in an upcoming Rapporteur meeting. Yes releaseComplete should have a cookie to address the active SDL. I didn't want to deviate from the legacy :). I will address this issue as well. Thanks for the reminder. … [View More]

3 3

Re: LogicalChannelRate Messages
by Paul Long 10 Nov '99

10 Nov '99

Aseem, Good point. Looks like an oversight. Using the other signaling entities, or SEs, as a guide, it appears that when there is a single SE per call, as is the case with CESE, no other information is required; however, when there can be multiple SEs per call, as is the case with CLCSE, RMSE, _and our "LCRSE"_, one must identify which instance of the incoming SE in the remote EP is being released. As a practical matter, I would say that upon receipt of LogicalChannelRateRelease as it is … [View More]

1 0

Re: H323 Mobility: About the work plan
by Roy, Radhika R, ALARC 10 Nov '99

10 Nov '99

Hi, Jaakko and All: Please see my reply provided below. I believe that we are in full agreement. Best regards, Radhika > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Wednesday, November 10, 1999 9:54 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H323Mobility: About the work plan > > Hi Radhika & others, > > Radhika has sent several messages indicating that he would like to see > complete mobility … [View More]solutions from Nokia as well as others. We do not think > that this is a good way to define the Annex H at this point. Furthermore, > we > think that this kind of approach is in conflict with what was agreed as > the > work plan in the Red Bank meeting. In our opinion we all agreed that the > next step is to finish the functional requirements and define the > functional > architecture including the reference points and descriptions of the > functional entities. [Roy, Radhika R] I guess that we are talking about the same thing. We are definitely defining the functional requirements as agreed in the Red Bank meeting. When people do not understand a functional requirement from conceptual point of view, the logical step is to see whether that functional requirement is supported by a solution. That does not mean that we should not include a function as "a place holder" to move forward because our final goal is to find a solution. You are welcomed to bring your proposals anytime. > If we all were to present our complete solutions (which I really doubt > that > all interested parties would be prepared to do), it would lead to several > very long contributions, say one from each of the following: AT&T, > Motorola, > Nokia, Ericsson, Siemens and Intel. Each of these contributions would > probably be in excess to 50 pages and very probably there would be great > differences between them. In order for us to be discussing the matter > based > on these contributions would require that everyone has fully analyzed each > of the contributions in such a way that possible weaknesses and/or clear > errors are found. This would require such an enormous workload that in > practice it would not be done and we would end up arguing about the matter > with quite limited knowledge of each other's ideas and in the end we would > probably produce some kind of lame compromise full of errors that have to > be > corrected afterwards. [Roy, Radhika R] Our final goal is to create standards to provide a solution. Companies are taking pains to bring contributions to provide a complete solution. We have no choice other than going through each proposal with due respect. We have to find pros and cons for each contribution. Then, we have to make a consensus decision based on technical merits. > Now, this does not mean that we shouldn't present example cases > (procedures) > based on the proposed architectural models, etc. Our view is that this > kind > of examples are both illustrative and necessary for understanding how the > system might work. However, we think that we do not need detailed message > definitions or even all the message sequences at this phase, the general > information flows are quite enough for examining the behavior of the > proposed architectures. In fact, we think that the next logical step in > the > Annex H standardization process would be the definition of the information > flows (i.e. what kind of information must be sent) between the functional > entities. After this kind of analysis has been made, it is much easier to > make the message and message field definitions (e.g. ASN.1) as well as the > message sequences in a way that is acceptable by at least the most of us. [Roy, Radhika R] Definitely, I agree with you. That is why we are providing comments on your proposal. You are always welcomed to put forward your proposals anytime you like unless you are not satisfied with all other alternative proposals. If you think that more architectural examples are needed to understand your points, please do so. Again, our final goal is to create standards to find a solution. > Nokia will present an architecture proposition in the near future, > hopefully > by the beginning of next week. [Roy, Radhika R] Beautiful. In this way, we will be able to get more insights for the problems for which all of us is looking for a solution. > - Jaakko Sundquist > ------------------------------------------------------- > In a hole in the ground there lived a hobbit. > Not a nasty, dirty, wet hole, filled with the ends of > worms and an oozy smell, nor yet a dry, bare, > sandy hole with nothing in it to sit down on or to eat: > it was a hobbit-hole, and that means comfort. > ------------------------------------------------------- [View Less]

1 0

H323Mobility: About the work plan
by Jaakko Sundquist 10 Nov '99

10 Nov '99

Hi Radhika & others, Radhika has sent several messages indicating that he would like to see complete mobility solutions from Nokia as well as others. We do not think that this is a good way to define the Annex H at this point. Furthermore, we think that this kind of approach is in conflict with what was agreed as the work plan in the Red Bank meeting. In our opinion we all agreed that the next step is to finish the functional requirements and define the functional architecture including … [View More]the reference points and descriptions of the functional entities. If we all were to present our complete solutions (which I really doubt that all interested parties would be prepared to do), it would lead to several very long contributions, say one from each of the following: AT&T, Motorola, Nokia, Ericsson, Siemens and Intel. Each of these contributions would probably be in excess to 50 pages and very probably there would be great differences between them. In order for us to be discussing the matter based on these contributions would require that everyone has fully analyzed each of the contributions in such a way that possible weaknesses and/or clear errors are found. This would require such an enormous workload that in practice it would not be done and we would end up arguing about the matter with quite limited knowledge of each other's ideas and in the end we would probably produce some kind of lame compromise full of errors that have to be corrected afterwards. Now, this does not mean that we shouldn't present example cases (procedures) based on the proposed architectural models, etc. Our view is that this kind of examples are both illustrative and necessary for understanding how the system might work. However, we think that we do not need detailed message definitions or even all the message sequences at this phase, the general information flows are quite enough for examining the behavior of the proposed architectures. In fact, we think that the next logical step in the Annex H standardization process would be the definition of the information flows (i.e. what kind of information must be sent) between the functional entities. After this kind of analysis has been made, it is much easier to make the message and message field definitions (e.g. ASN.1) as well as the message sequences in a way that is acceptable by at least the most of us. Nokia will present an architecture proposition in the near future, hopefully by the beginning of next week. - Jaakko Sundquist ------------------------------------------------------- In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort. ------------------------------------------------------- [View Less]

1 0

Re: H323 mobility: Summary of discussion
by Roy, Radhika R, ALARC 10 Nov '99

10 Nov '99

Hi, Adam and All: We have requested everyone to provide contributions with solutions. We will then be able to understand what exactly they mean. With respect to your questions, it is too early to answer. However, we will be getting there soon as we are making progress to find a solution. Once we define an H.323 mobility architecture, we will definitely be able to relate all other wireless networks as well. Please note that H.323 mobility architecture is good for both wire-line and wireless … [View More]network. By the way, if your provide a contribution, it will help us to understand about your proposed solution. Best regards, Radhika R. Roy > -----Original Message----- > From: Adam Li [SMTP:adamli@ICSL.UCLA.EDU] > Sent: Wednesday, November 10, 1999 4:41 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323 mobility: Summary of discussion > > Hi, all, > > Barry Aronson's comment seems to make a lot of sense to me. > > I am new to the H.323 group, but I've been reading the email > correspondences here for quite a while. May I ask a few dumb > questions, and please correct me and elighten me if I am wrong? > > Question: Consider the wireless case, isn't that H.323M is > going to be used over some wireless network (e.g. 3G IMT2000 > network)? If such network is already built to ensure that your > data gets transmitted to you no matter you walk or drive from > one zone to the other, why can't our H.323M terminal just > sit at the handset and wait for our data get routed to us > by the network? Or, why do we need to duplicate these > functions that are already provided, and should be provided > by the network layer? > > Maybe, all we have to do is to make sure we know the data is from > the same entity when it changes its attaching point, since each > H.323 entity is identified by the LAN address (H.323 7.1.1). > A simple extension of assigning a temporary ID number to each > entity or to each conference can solve that. > > Please enlighten if there is any special compelling reason that > I might have overlooked for duplicating an entire mobile network > functionality within H.323. Thanks in advance. > > Adam Li > > > Edgar Martinez [1] writes: > > > > Comments: follow-- > > > > Barry Aronson wrote: > > > > > All, > > > > > > I agree with Tom. We seem to be headed for designing an entire mobile > > > network within H.323 -- definitely a case of the tail wagging the dog. > If > > > this was the desire, extending existing mobile networks (AMPS, GSM, > etc.) to > > > include H.323 terminals would be simpler. > > > > This is called the WAP solution, already done but it is still > > two separate networks (MSC-CS and PDN) routed/ split out > > by a DSU from the BSC. And it does not address the fixed > > Internet PC or any PSTN/ISDN interworking. > > > > > That is, of course, unless you > > > wanted the terminals to be independent of the physical network from > the > > > network layer on up. H.323 could do this if there was an underlying > packet > > > based network -- probably IP. Using IP as a common network layer for > both > > > wireless and wired terminals is of course all the rage these days. > Given > > > that universal wireless terminals are been worked as part of IMT-2000 > (and > > > 3GPP, 3GPP-2, etc.), wouldn't it make sense to define the Annex H > issues > > > being debated in the appropriate network groups? > > > > We are looking at the H.323 mobility at the appilation layer within > > the approriate woking groups. > > > > > > > > > > > > > Maybe I misunderstood, but I thought in Santiago the purpose of Annex > H and > > > I was to make H.323 work within the context of a mobile terminal > and/or > > > user, and also allow for service mobility. > > > > I feel a mobile IP debate is in the starts here but, We are looking at > > the H.323 mobility at the appilation layer within the approriate woking > > group. > > > > What the IETF needs to address is how mobile IP interworks with Mobility > > whether is H.323, GSM, PLNM or otherwise.. > > > > > I don't think any of what is > > > being discussed for Annex H is necessary to achieve this. > > > > What being discussed here is, we are looking at > > the H.323 mobility from the appilation layer. > > > > > > > > > > > Barry > > > > > > -----Original Message----- > > > From: Mailing list for parties associated with ITU-T Study Group 16 > > > [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Tom-PT Taylor > > > Sent: Friday, November 05, 1999 11:17 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: H323 mobility: Summary of discussion > > > > > > I think a basic point in this discussion is that mobility is "bigger > than" > > > H.323 and already has well-established architectural underpinnings. > It's > > > all very well to talk about an H.323 solution which we could then > adapt, but > > > we would more likely end up with an H.323-only solution as a result. > The > > > concern then would be whether vendors saw sufficient opportunity in > building > > > to this market, compared with the general market for mobility > products. > > > > -- > > Edgar Martinez - Principal Staff Engineer > > Email mailto:martinze@cig.mot.com > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > > > > -- > Adam H. Li > Image Process Lab > University of California - Los Angeles > (Phone) 310-825-5178 (Fax) 310-825-7928 [View Less]

1 0

Re: H323 mobility: Summary of discussion
by Edgar Martinez [1] 10 Nov '99

10 Nov '99

Comments: follow-- Barry Aronson wrote: > All, > > I agree with Tom. We seem to be headed for designing an entire mobile > network within H.323 -- definitely a case of the tail wagging the dog. If > this was the desire, extending existing mobile networks (AMPS, GSM, etc.) to > include H.323 terminals would be simpler. This is called the WAP solution, already done but it is still two separate networks (MSC-CS and PDN) routed/ split out by a DSU from the BSC. And it does not … [View More]address the fixed Internet PC or any PSTN/ISDN interworking. > That is, of course, unless you > wanted the terminals to be independent of the physical network from the > network layer on up. H.323 could do this if there was an underlying packet > based network -- probably IP. Using IP as a common network layer for both > wireless and wired terminals is of course all the rage these days. Given > that universal wireless terminals are been worked as part of IMT-2000 (and > 3GPP, 3GPP-2, etc.), wouldn't it make sense to define the Annex H issues > being debated in the appropriate network groups? We are looking at the H.323 mobility at the appilation layer within the approriate woking groups. > > > Maybe I misunderstood, but I thought in Santiago the purpose of Annex H and > I was to make H.323 work within the context of a mobile terminal and/or > user, and also allow for service mobility. I feel a mobile IP debate is in the starts here but, We are looking at the H.323 mobility at the appilation layer within the approriate woking group. What the IETF needs to address is how mobile IP interworks with Mobility whether is H.323, GSM, PLNM or otherwise.. > I don't think any of what is > being discussed for Annex H is necessary to achieve this. What being discussed here is, we are looking at the H.323 mobility from the appilation layer. > > > Barry > > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group 16 > [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Tom-PT Taylor > Sent: Friday, November 05, 1999 11:17 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H323 mobility: Summary of discussion > > I think a basic point in this discussion is that mobility is "bigger than" > H.323 and already has well-established architectural underpinnings. It's > all very well to talk about an H.323 solution which we could then adapt, but > we would more likely end up with an H.323-only solution as a result. The > concern then would be whether vendors saw sufficient opportunity in building > to this market, compared with the general market for mobility products. -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ [View Less]

2 1