- sg16-avd - lists.packetizer.com

On TD26 - Fast TCS and M/S negotiation in H.323v4
by Pete Cordell 30 May '00

30 May '00

I note that TD-26 has been accepted to show how TCS can be conveyed in parallel with fast start. However, the example shows the use of call proceeding for receiving TCS back from the remote endpoint. This is not typically an end-to-end message, and therefore how the procedure works with the gatekeeper routed model needs to be addressed. Possible solutions are: 1. Refer to the new text that says it is the responsibility of the gatekeeper to forward any tunnelled message for which none is available using FACILITY. (There might be some objection from some to using a facility message this early in the call setup process though.) 2. Restrict the tunnelling (and probably the fast start info) to Alerting, Connect and Facility, which generally are end-to-end. I believe this is compatible with the latest procedures for deciding when fast start has been ignored. Which ever option is chosen, it would also be nice to have a picture for it also! Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 4

FW: MEGACO errata
by Tom-PT Taylor 29 May '00

29 May '00

I'm forwarding this to the SG 16 list copy the Megaco list because I think the MTP address was firmed up at Red Bank. Can anyone account for the failure to accommodate longer MTP addresses? Was it simply because the intention was to use Annex I transport within an ITU environment only? > -----Original Message----- > From: dacollins(a)notes.primeco.com [SMTP:dacollins@notes.primeco.com] > Sent: Friday, May 26, 2000 1:03 PM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Subject: MEGACO errata > > > > Hi Tom, > Having had a look at the latest version of the MEGACO spec, I noticed > something > odd. The mId may be an MTP address. However, the MTP address is defined in > both > the ABNF and ASN.1 specifications as being 2 octets in length. The ASN.1 > description provides a comment that the point code (PC) is 14 bits and the > network indicator (NI) is two bits. > This is only correct for the ITU version of SS7. > In several countries, different versions of SS7 are used and different > addressing schemes are used. In many countries, including the US, Canada > and > China, the PC is 24 bits long, with the NI still at two bits, for a total > of 26 > bits. Therefore, to use an MTP address for the mId in those countries, the > definition of the mId needs to change. > > I hope this helps in finalizing the spec. > > Daniel Collins > >

2 1

Re: H.323 Annex O
by Roni Even 28 May '00

28 May '00

Roy, The summary from Q14 states that SIP-H.323 interworking will be an appendix that will map messages for simple audio calls. and would defines preferred interworking mode. See the text bellow from TD-21b Roni Even 6.1.1 APC-1776 - Terms of Reference for H.323 - Internet Interworking [H.323-Internet Interworking Group] [joint with Q.12, Q.13] Q.15 discussed some SIP matters - SDP does not currently provide enough detail to describe H.263+ parameters. Call signaling could be captured in an appendix to H.246. This appendix would first address simple audio interworking, covering topics such as mapping messages between H.323 and SIP. This is work that is currently in progress in the IETF (not an official work item at this time, but an unofficial task in the SIP working group). This appendix would define the "preferred interworking mode" of H.323; we'd expect the SIP experts to define the preferred interworking mode of SIP. We need to capture the essence of each of the functional entities. Contributions are requested. There was agreement that a new annex to H.323 to address how H.323 could utilize a variety of internet services. Section 3 of APC-1776 is a good basis for this work. > -----Original Message----- > From: Roy, Radhika R, ALARC [SMTP:rrroy@ATT.COM] > Sent: Fri, May 26, 2000 9:30 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323 Annex O > > Mr. M. F. TOSCO > Chairman > ITU-T SG16 WP2 > > Dear Mr. TOSCO: > > We are very much pleased to see that an H.323 Annex O (Internet Protocols > and Technologies Complementary to H.323) has been opened in the joint > meeting of Q.13/16 and Q.13/16 held in Osaka, Japan on May 15-19, 2000. It > is expected that this annex will cover the following topics: > > 1. H.323-SIP Interworking > 2. Inteworking between H.323 and other IETF Protocols (e.g., TRIP, > etc.) > > With respect to item 1 (H.323-SIP Interworking), it has been noted in the > meeting report that the IETF is also working to develop an Informational > RFC > (a standard track RFC is also a possibility) for the SIP-H.323 > interworking. > The way this work in the IETF is progressing is as follows (I believe that > the editor of H.323 Annex O is also fully aware of this work of the IETF): > > 1. SIP-H.323 Interworking Requirements RFC (Informational): by > July-December, 2000 (tentative) > 2. SIP-H.323 Interworking RFC (Informational): December 2000 - March > 2001 (tentative) > > The Internet-Drafts and documents that are being provided to develop the > RFC > are as follows: > > 1. Agrawal, Roy, and Palawat, "SIP-H.323 Interworking Requirements," > draft-agrawal-roy-palawat-sip-h323-interworking-00.txt, IETF, June 2000. > 2. Singh and Schulzrinne, "Interworking Between SIP/SDP and H.323", > draft- singh-sip-h323-00.txt, IETF, January 2000. > 3. C. Agbah, "SIP and H.323 Signaling Gateway." > > It is expected that the SIP-H.323 Interworking RFC will be based primarily > on the above documents along with suggestions made via emails and > conference > calls. > > People could take many those contributions to the ITU-T SG16 for the > SIP-H.323 Interworking in the last SG16 February'00 meeting. However, it > was > found that many companies and institutions that invented the interworking > solution could not afford to provide the membership fees of the ITU-T, and > some of them even could not afford to make a foreign trip for the standard > meeting. But this has not been the case for the IETF where the email has > been good enough to work for developing the standard. > > Therefore, I am proposing the following to harmonize the work of these two > organizations so that the complementary standards are created in the ITU-T > SG16 and IETF: > > 1. Let the IETF produce the SIP-H.323 interworking RFC, while we, the > ITU-T SG16, will develop the H.323-TRIP and/or other IETF protocols > Interworking standard. > 2. Should the IETF do not develop the standard track SIP-H.323 RFC, > we, > the ITU-T SG16, might consider how IETF's SIP-H.323 Interworking > (Informational) RFC can be made a formal standard. > > I hope this suggestion will be acceptable to all of us. > > Best regards, > > Radhika R. Roy > AT&T Delegation Manager in the ITU-T SG16 (WP1, WP2, & WP3) > 200 Laurel Avenue, Middletown, NJ 07748, USA > +1 732 420 1580 Tel > +1 732 368 1195 Fax > rrroy(a)att.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: FW: MEGACO errata
by Chip Sharp 26 May '00

26 May '00

I looked back through my files. It was set to 5 octets in TD33 that was submitted to SG16 in Geneva. I've got a marked up version of TD-33a created 5 pm on 2/13 that still has 5 octets in it. TD-102 that was produced on 2/15/00 had it changed to 2 octets. I could not find any contributions, delayed contributions or TDs that suggested changing this value, so I can only assume it was added during the discussions between 2/13 (Sun) and 2/15 (Tues). At 03:08 PM 5/26/00 -0500, Tom-PT Taylor wrote: >I'm forwarding this to the SG 16 list copy the Megaco list because I think >the MTP address was firmed up at Red Bank. Can anyone account for the >failure to accommodate longer MTP addresses? Was it simply because the >intention was to use Annex I transport within an ITU environment only? >-----Original Message----- From: dacollins(a)notes.primeco.com >[SMTP:dacollins@notes.primeco.com] Sent: Friday, May 26, 2000 1:03 >PM To: Taylor, Tom-PT [NORSE:B901:EXCH] Subject: MEGACO errata > > > >Hi Tom, Having had a look at the latest version of the MEGACO spec, I >noticed something odd. The mId may be an MTP address. However, the MTP >address is defined in both the ABNF and ASN.1 specifications as being 2 >octets in length. The ASN.1 description provides a comment that the point >code (PC) is 14 bits and the network indicator (NI) is two bits. This is >only correct for the ITU version of SS7. In several countries, different >versions of SS7 are used and different addressing schemes are used. In >many countries, including the US, Canada and China, the PC is 24 bits >long, with the NI still at two bits, for a total of 26 bits. Therefore, >to use an MTP address for the mId in those countries, the definition of >the mId needs to change. > >I hope this helps in finalizing the spec. > >Daniel Collins ------------------------------------------------------------------- Chip Sharp CTO Consulting Engineering Cisco Systems Reality - Love it or Leave it. http://www.netaid.org ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: FW: MEGACO errata
by Chip Sharp 26 May '00

26 May '00

In your email "Changes made in Geneva" is the following cryptic statement: ...snip... >Annex A.2 > -- comment sets initial version to 1 > -- mtpAddress size corrected ...snip... I don't remember what this meant and I don't remember much of Geneva, but I seem to remember this issue coming up somewhere. Hopefully this will give you a pointer to start with. Chip At 03:08 PM 5/26/00 -0500, Tom-PT Taylor wrote: >I'm forwarding this to the SG 16 list copy the Megaco list because I think >the MTP address was firmed up at Red Bank. Can anyone account for the >failure to accommodate longer MTP addresses? Was it simply because the >intention was to use Annex I transport within an ITU environment only? >-----Original Message----- From: dacollins(a)notes.primeco.com >[SMTP:dacollins@notes.primeco.com] Sent: Friday, May 26, 2000 1:03 >PM To: Taylor, Tom-PT [NORSE:B901:EXCH] Subject: MEGACO errata > > > >Hi Tom, Having had a look at the latest version of the MEGACO spec, I >noticed something odd. The mId may be an MTP address. However, the MTP >address is defined in both the ABNF and ASN.1 specifications as being 2 >octets in length. The ASN.1 description provides a comment that the point >code (PC) is 14 bits and the network indicator (NI) is two bits. This is >only correct for the ITU version of SS7. In several countries, different >versions of SS7 are used and different addressing schemes are used. In >many countries, including the US, Canada and China, the PC is 24 bits >long, with the NI still at two bits, for a total of 26 bits. Therefore, >to use an MTP address for the mId in those countries, the definition of >the mId needs to change. > >I hope this helps in finalizing the spec. > >Daniel Collins ------------------------------------------------------------------- Chip Sharp CTO Consulting Engineering Cisco Systems Reality - Love it or Leave it. http://www.netaid.org ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323 Annex O
by Roy, Radhika R, ALARC 26 May '00

26 May '00

Mr. M. F. TOSCO Chairman ITU-T SG16 WP2 Dear Mr. TOSCO: We are very much pleased to see that an H.323 Annex O (Internet Protocols and Technologies Complementary to H.323) has been opened in the joint meeting of Q.13/16 and Q.13/16 held in Osaka, Japan on May 15-19, 2000. It is expected that this annex will cover the following topics: 1. H.323-SIP Interworking 2. Inteworking between H.323 and other IETF Protocols (e.g., TRIP, etc.) With respect to item 1 (H.323-SIP Interworking), it has been noted in the meeting report that the IETF is also working to develop an Informational RFC (a standard track RFC is also a possibility) for the SIP-H.323 interworking. The way this work in the IETF is progressing is as follows (I believe that the editor of H.323 Annex O is also fully aware of this work of the IETF): 1. SIP-H.323 Interworking Requirements RFC (Informational): by July-December, 2000 (tentative) 2. SIP-H.323 Interworking RFC (Informational): December 2000 - March 2001 (tentative) The Internet-Drafts and documents that are being provided to develop the RFC are as follows: 1. Agrawal, Roy, and Palawat, "SIP-H.323 Interworking Requirements," draft-agrawal-roy-palawat-sip-h323-interworking-00.txt, IETF, June 2000. 2. Singh and Schulzrinne, "Interworking Between SIP/SDP and H.323", draft- singh-sip-h323-00.txt, IETF, January 2000. 3. C. Agbah, "SIP and H.323 Signaling Gateway." It is expected that the SIP-H.323 Interworking RFC will be based primarily on the above documents along with suggestions made via emails and conference calls. People could take many those contributions to the ITU-T SG16 for the SIP-H.323 Interworking in the last SG16 February'00 meeting. However, it was found that many companies and institutions that invented the interworking solution could not afford to provide the membership fees of the ITU-T, and some of them even could not afford to make a foreign trip for the standard meeting. But this has not been the case for the IETF where the email has been good enough to work for developing the standard. Therefore, I am proposing the following to harmonize the work of these two organizations so that the complementary standards are created in the ITU-T SG16 and IETF: 1. Let the IETF produce the SIP-H.323 interworking RFC, while we, the ITU-T SG16, will develop the H.323-TRIP and/or other IETF protocols Interworking standard. 2. Should the IETF do not develop the standard track SIP-H.323 RFC, we, the ITU-T SG16, might consider how IETF's SIP-H.323 Interworking (Informational) RFC can be made a formal standard. I hope this suggestion will be acceptable to all of us. Best regards, Radhika R. Roy AT&T Delegation Manager in the ITU-T SG16 (WP1, WP2, & WP3) 200 Laurel Avenue, Middletown, NJ 07748, USA +1 732 420 1580 Tel +1 732 368 1195 Fax rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Versions of Annex E
by Paul E. Jones 26 May '00

26 May '00

Folks, There is a copy of Annex E here: ftp://standard.pictel.com/avc-site/9905_San/Annex_E_rev7.1_changes.zip that appears to be newer, but in fact has no official standing. Mr. Okubo's HTML document describes that it was a proposal to the Santiago meeting, but I've seen a couple of people download it without reading the HTML file, believing that it was the current version. Mr. Okubo, is there something we can do to help prevent people from mistaking this for the latest version? Can we modify the timestamp of the file or rename it? Thanks, Paul

3 3

Re: [H.323 Mobility:] Status check & practical things
by Roy, Radhika R, ALARC 26 May '00

26 May '00

Hi, Jaakko and All: Thanks for clarifications that you will produce a new H.323 Annex H that will be basis for discussions and bringing contributions. It will also be noted that further clarifications have been provided by me related to the MGA message via email in the SG16 reflector because TD-56 does NOT reflect the correct view. It has been observed rightly by you that we could not make sufficient progress in the last teleconferences. If Mr. Korpi makes frequent travels, our progress may be slow. Going forward we have the following to do: 1. We will start email discussions as far as practicable on continuous basis and update the document at a certain interval as appropriate based on the conclusion made via email. Email discussions are very helpful (also legitimate) because people can take their time to think about the matter and provide responses appropriately. Moreover, the email goes to the every member of the SG16. 2. We will also participate in the teleconferences as we will be deciding very soon (Mr. Korpi will help us). If any member has any questions related to the process, please let us know. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > Sent: Friday, May 26, 2000 7:10 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [H.323 Mobility:] Status check & practical things > > Hi folks, > > In this mail, I will try to summarize the current status of H.323 Annex H > work as well as introduce some practical issues concerning our work before > the Portland meeting. > > The Annex H draft outcome from the Osaka meeting can be seen in document > TD-47. Also TD-28, which contains the explanation of the scopes of the > three > mobility related annexes as well as TD-56, which contains the meeting > minutes of the ad hoc group meetings in Osaka are relevant to the Annex H > work. > > I will produce a new draft of Annex H hopefully in a few days, containing > most of the contents of TD-28 in the Introduction chapter (chapter 2). > After > this has been done, we can consider the document as the outcome of the > Osaka > meeting and as a baseline to be addressed in the MTD contributions. > > Work concerning the new service definitions chapter (chapter 5) was also > started in Osaka by Mr. Korpi and Mr. Reddy. The original idea was to > produce a TD in the Osaka meeting, but as time did not allow that, I > anticipate that Mr. Korpi and Mr. Reddy will produce an MTD in the near > future. > > The next issues I would like to focus on, are the rewriting of chapter 7 > concerning the functional requirements as well as continuing the work on > the > information flows and the associated message contents. My feeling is that > chapter 7 in its current form is actually quite poor and frankly quite > confusing and thus needs to be rewritten properly. > > Then to the practical things concerning our work. As Mr. Paul Guram had to > withdraw from the position of the unofficial chairman of the ad hoc group, > it was decided that Mr. Korpi will take that position in the future > meetings > and teleconferences. I think I can speak on behalf of the whole ad hoc > group > when I thank Mr. Guram for doing such an excellent work as the chairman, > you > have been a great help for us. > > Because Mr. Korpi is travelling quite a lot, he did not feel that he > should > be allocating the MTD numbers, so I volunteered to do that. Thus, if (and > hopefully when) you have a contribution for the interim work, please ask > for > an MTD number from me. > > I also propose that we will try to do more work by using the email > reflector > and have teleconferences only a few times before the Portland meeting. > This > is because my feeling is that we really have not had much success in > progressing the work in the teleconferences. We will also agree the dates > for the teleconferences in the reflector. I will also try to produce a new > draft of the Annex H approximately twice per month (my vacation time > excluded) so that you'll have something concrete to argue against or to > support. Anyway, contributions are always very welcome and if the > discussions in the reflector and teleconferences seem to be in agreement, > the contents of the contributions will be added to the draft as soon as > possible. > > ------------------------------------------------ > Jaakko Sundquist * > +358 50 3598281 * Audere est Facere! > jaakko.sundquist(a)nokia.com * > ------------------------------------------------ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[H.323 Mobility:] Status check & practical things
by Jaakko Sundquist 26 May '00

26 May '00

Hi folks, In this mail, I will try to summarize the current status of H.323 Annex H work as well as introduce some practical issues concerning our work before the Portland meeting. The Annex H draft outcome from the Osaka meeting can be seen in document TD-47. Also TD-28, which contains the explanation of the scopes of the three mobility related annexes as well as TD-56, which contains the meeting minutes of the ad hoc group meetings in Osaka are relevant to the Annex H work. I will produce a new draft of Annex H hopefully in a few days, containing most of the contents of TD-28 in the Introduction chapter (chapter 2). After this has been done, we can consider the document as the outcome of the Osaka meeting and as a baseline to be addressed in the MTD contributions. Work concerning the new service definitions chapter (chapter 5) was also started in Osaka by Mr. Korpi and Mr. Reddy. The original idea was to produce a TD in the Osaka meeting, but as time did not allow that, I anticipate that Mr. Korpi and Mr. Reddy will produce an MTD in the near future. The next issues I would like to focus on, are the rewriting of chapter 7 concerning the functional requirements as well as continuing the work on the information flows and the associated message contents. My feeling is that chapter 7 in its current form is actually quite poor and frankly quite confusing and thus needs to be rewritten properly. Then to the practical things concerning our work. As Mr. Paul Guram had to withdraw from the position of the unofficial chairman of the ad hoc group, it was decided that Mr. Korpi will take that position in the future meetings and teleconferences. I think I can speak on behalf of the whole ad hoc group when I thank Mr. Guram for doing such an excellent work as the chairman, you have been a great help for us. Because Mr. Korpi is travelling quite a lot, he did not feel that he should be allocating the MTD numbers, so I volunteered to do that. Thus, if (and hopefully when) you have a contribution for the interim work, please ask for an MTD number from me. I also propose that we will try to do more work by using the email reflector and have teleconferences only a few times before the Portland meeting. This is because my feeling is that we really have not had much success in progressing the work in the teleconferences. We will also agree the dates for the teleconferences in the reflector. I will also try to produce a new draft of the Annex H approximately twice per month (my vacation time excluded) so that you'll have something concrete to argue against or to support. Anyway, contributions are always very welcome and if the discussions in the reflector and teleconferences seem to be in agreement, the contents of the contributions will be added to the draft as soon as possible. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility] clarification
by Laurent Thiebaut 26 May '00

26 May '00

I apologize for having sent on the e_mail exploder an mail in French and I send it again with english version The calling party (and his GK) cannot only know whether a called party is fixed or mobile if this called party belongs to the same country (same numbering plan) and this may even be no more true if Number Portablity applies. A French GK has at my knowledge no clue on the Australian or swedish numbering plan Best regards and again apologizes for the french message Laurent . --------------------------------------------------------------------------- V Laurent Thiebaut tel: +33 (0)1 3077 0645 A L C A T E L e.mail:laurent.thiebaut@alcatel.fr --------------------------------------------------------------------------- Laurent Thiebaut <Laurent.Thiebaut(a)ALCATEL.FR> on 26/05/2000 09:53:59 Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Laurent THIEBAUT/FR/ALCATEL) Subject: Re: [H.323 Mobility] clarification Francois-Xavier je ne connais pas le contexte mais a priori: le calling party (et son GK) ne peuvent savoir que l'appelé est un mobile que si cet appelé apprtient au meme pays. Un GK francais n'a a mon avis aucune idee du plan de num Australien ou suedois J'organise lundi une réunion de debriefing du dernier 3GPP R00. Si ca t'interresse. laurent Francois-Xavier Derome <Francois-Xavier.Derome(a)ALCATEL.FR> on 25/05/2000 13:13:17 Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Laurent THIEBAUT/FR/ALCATEL) Subject: [H.323 Mobility] clarification hi, Before writing a contribution for the annex H, I have a question for clarification. I didn't see a requirement that the calling party and the calling GK should not be aware that the called party is a mobile user and is eventually at a visiting location. What is the feeling of the group ? Shouldn't we add this requirement in the annex or does anybody disagree with it ? fx ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0