Hi All, H.GCP version I promised for today will not be available until Monday. . . I need the weekend to finish it off, Sorry about they delay
Have a good weekend,
Bryan
-----Original Message----- From: Greene, Nancy-M [CAR:5N10:EXCH] [SMTP:ngreene@americasm01.nt.com] Sent: Thursday, April 08, 1999 4:23 PM To: 'megaco@baynetworks.com'; 'itu-sg16@mailbag.intel.com' Subject: audio call Thursday: Minutes
Minutes of the IETF/ITU Megaco/H.GCP audio call held April 8, 1999, 11am-1pm EDT
22 people participated, with participants from IETF Megaco, and from ITU-T SG16.
Topics discussed: a) issues with the current Megaco protocol internet-draft (draft-ietf-megaco-protocol-00.txt) b) status on folding this work into H.gcp c) report on US Study Group D meeting April 6th/99 d) miscellaneous
Action items: i) Next version of documents: April 9th: Bryan Hill will release the current version of H.gcp April 16th: Brian Rosen will release an new version of the Megaco protocol internet-draft. He will coordinate with Bryan Hill, to also get out a new version of H.gcp at that time that is as identical as possible to the new internet-draft.
ii) Tom Taylor volunteered to produce write-up explaining two approaches for handling H.320 gateways - input will come from email msgs sent out on this topic by Brian Rosen and Paul Sijben.
iii) Tom Taylor will put together an Issues List, where each issue is described, zero or more resolutions proposed, and there will be a tag marking the issue as open or closed. All editor's notes will be pulled out of the body of the internet-draft/H.gcp, and put in the issues list, with references back to the internet-draft. The issues list will be included in each revision of the internet-draft/H.gcp.
Next meeting: - no date was set for an audio call. There was some discussion on having one some time before April 21st. If one is scheduled, it will be announced on the ITU-SG16 and megaco reflectors.
Detailed report:
Brian Hill opened the meeting.
a) issues with the current Megaco protocol internet-draft (draft-ietf-megaco-protocol-00.txt) As stated above, Tom Taylor will put together an Issues List, where each issue is described, zero or more resolutions proposed, and there will be a tag marking the issue as open or closed. All editor's notes will be pulled out of the body of the internet-draft/H.gcp, and put in the issues list, with references back to the internet-draft. The issues list will be included in each revision of the internet-draft/H.gcp.
Issues discussed in the audio call today:
1) association of contexts and terminations - is the context model, with one media type per context, adequate for multimedia?
Tom Taylor says he believes the current context model with one media type per context is adequate. Brian Rosen explained that keeping it this way simplifies things for the common case where there is just one media type per call (i.e. audio). Paul Sijben would still prefer to allow multiple media types per context. When there was just one media type, the fields identifying media type, or separate media streams would be optional. Brian Rosen is still not convinced.
Conclusion: Tom Taylor volunteered to produce a write-up explaining the two approaches for handling H.320 gateways - input will come from email msgs sent out on this topic by Brian Rosen and Paul Sijben. We agreed that figures for this discussion can be distributed in pdf instead of ascii.
Discussion on what you would need to synchronize between contexts: - lip synch - issue - do you link contexts, or do you link a particular termination in a context to a particular termination in another context? How do you know that the video stream going out is the one that you want to lip sync with the audio stream going out? If you were lipsynching the current speaker and you knew that both the audio and video were of the current speaker, you could lipsync the contexts. But what if the video stream going out was NOT the one related to the audio? - synchronize closed captioning - synchronize the switching of streams being sent based on current speaker
2) H.245 capability negotiation Tom Taylor explained that the capability negotiaton stage is done between MGCs, and thus does not need to be expressable in the Megaco protocol - this negotiation is done BEFORE connection setup. Audit allows the MGC to discover what capabilities the MG has, but it does not give information on mutually exclusive choices based on processing power availability, for example.
Need to walk through the example of Test Case 1 that Tom put out before the last IETF meeting, where the terminating MG may choose G.711 or G.729 - does the originating MG reserve both G.711 and G.729 for the termination, or just one of the two, and then modify it based on what the terminating MG chose? The test case allows G.711 in one direction and G.729 in the other.
3) attributes per termination class - these need more detail
4) how to extend the protocol - this needs to be spelled out
5) event handling - currently an event is identified to the MGC with an eventId - Paul Sijben suggested that it would be better to use a terminationId
6) terminationIds - there was a question whether terminationIds were logical or physical, i.e., would you put the word audio in a terminationId to make it a logical name? The answer was NO, a terminationId is a name of a physical termination, not a logical one.
7) transport issues There was discussion on what to use for interoperability purposes until the actual transport is agreed on. Some people wanted to mandate TCP for the MG, others said UDP + the message acks, + the addition of timers would be better. Are there MG manufacturers that do not want to put TCP in their MGs, even if only for demonstration purposes? If there is opposition to TCP even for demonstration purposes, then we would go with UDP + message acks, + timers. Chip Sharp reminded us that SGCP worked just fine with UPD, acks, and timers. ===> An issue for the mailing list.
8) security issues - no one had issues with security as it is described in the Megaco protocol internet-draft
9) syntax issues - discussion on this issue was deferred
10) Handling of NAS - can the protocol handle dial-out? this should be no problem - indication that the NAS wishes to dial out would be an event from the NAS (MG) to the MGC (NAS Controller), then the MGC issues an Add into a new context. - if the MGC does directory lookup to an AAA server, and there are Radius attributes to pass to the NAS, these need to be spelled out ===> need to make sure the foundations are in place to handle NAS. If termination classes, etc. for NAS are not ready for this internet-draft, they can go in as a separate RFC. But we will try to get them ready in time.
b) status on folding this work into H.gcp As mentioned in the Action Items list above, Brian Hill, the H.gcp editor, will be releasing the current version of H.gcp tommorrow. It has much of the Megaco internet-draft folded into it. Everyone agreed that we want to keep these two protocols aligned, and identical if at all possible. When Brian Rosen releases a new version of the internet-draft by April 16th, he will coordinate with Bryan Hill to get this version into a new version of H.gcp as well.
A question was asked on what a determined document means in the ITU? Tom Taylor answered that it means the technical directions are firmly set.
A document that is to be decided at an ITU meeting must be ready four months before the actual meeting. In this case, it means it must be ready by Nov/99 (white paper deadline) to be decided at the Feb/2000 SG16 meeting.
If interoperability testing of the protocol starts in early fall, there will be time to feed any corrections needed into the protocol before the Nov/99 white paper deadline.
With all this cooperation, there is a feeling that there is a good chance to get one common protocol document between the IETF and the ITU.
c) report on US Study Group D meeting April 6th/99 It seems there is still an issue that the US may oppose determining a document they haven't seen yet, unless there is "overriding industry interest" in having the document determined. So, any US company interested in having H.gcp determined should make their interest in determining H.gcp known.
d) miscellaneous Chip Sharp asked who is using H.226. No one on the call was.
Meeting Conclusion: See above for action items.
-end of the meeting-
Nancy
-------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com