- sg16-avd - lists.packetizer.com

H.323 Annex F - SET questions
by Gunnar Hellstrom 18 Apr '99

18 Apr '99

Dear Jörg and all, When preparing H.323 Annex G - Text SET, I studied the base SET document; Annex F as in TD11 from Monterey, and came across a few points raising questions. I hope I can get clarifications on these points. 1. In section 6. it is said that for the Audio SET, "Data-capability is optional - possibly support for facsimile transmission." If this section is as is stated - for the Audio SET, then "No Data Capability" should be specified. And I think that is a good structure - Then I can write that the Text SET has Media Capabilities as for the Audio Set but with Data Capability for text conversation according to T.140. 2. In section 7.3.2. the explanations of the abbreviations M O I N, refers to Audio SET devices. The rest of this section looks general, why I suggest that the word "Audio" should be deleted in these four explanations. 3. Media Exchange. Insert TCP among the allowed protocols, so that data transmission SET:s can be allowed. 4. In section 7.6.1, the last sentence is "The OpenLogicalChannel structure should offer the same audio encodings that were in use prior to call rerouting." Looking back to the discussions in the list the last few weeks, I find that this sentence is misleading and can safely be deleted. The result should be that coding changes and media additions shall be allowed to occur after the rerouting. 5. In section 7.6.2, change the word "resume" to "start" in the last sentence. Since media additions may occur, media streams may be new after the rerouting. 6. Terminal type for SET types. I want to discuss the "Endpoint Type" specification in H.225.0 as described among the additions to implementor´s guides, titled "Addition of a terminal type for Simple Endpoint Types"and in Annex F, section 7.1. Bit 0 =1 if the device is an Audio SET. My question is: Should this specifier rather mark available functions than complete SETs? Then, bit 0 could indicate "the device has Audio functions" and , bit 2 could indicate "the device has Text conversation features." A Text SET should set them booth. This would allow for a combined text - fax - audio -SET. Regards Gunnar Hellström ------------------------------------------------ Gunnar Hellström Omnitor AB Alsnögatan 7, 4tr S-116 41 Stockholm SWEDEN Tel +46 751 100 501 Fax +46 8 556 002 06 E-mail: gunnar.hellstrom(a)omnitor.se WWW: www.omnitor.se ------------------------------------------------

1 0

Re: H.245 vs. SDP
by Mike Buckley 16 Apr '99

16 Apr '99

Thanks for the clarification Tom. This is exactly what I meant. I agree that caps exchange will generally be a registration process. However I would pose a question whether there might not be a need for a caps exchange after registration to identify resources temporarily unavailable (traffic loading etc) or unavailable in a specific set of circumstances. Also is there a role for a caps exchange to change parameters during a session? This might be particularly important in multimedia situations. Mike ____________________ Begin Original Message ___________________________ Date: Fri Apr 16 09:24:57 -0400 1999 From: internet!NORTELNETWORKS.COM!taylor (Tom-PT Taylor) Subject: H.245 vs. SDP To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO Content-Type: Generic-Text Content-Length: 4210 I would like to clarify the issue of H.245 vs. SDP. First off, what we are talking about here is NOT capability negotiation. The latter is handled by signalling between MGCs. A given MGC obtains the information needed to support its end of the negotiation through use of the Audit command. Megaco/H.GCP has the action to ensure that responses to Audit commands convey the necessary information. That said, the question becomes one of SDP vs. the H.245 OpenLogicalChannel (OLC) and OLC Ack structures. I think what Mike is saying is that there are two issues in this discussion: content, and ordering of that content. On content, I think we can get general agreement that if the H.245 OLC can request something, the Media Gateway control protocol should be able to propagate that request to the MG. Thus there is no argument in general over content, leaving aside housekeeping items like the H.245 logical channel number which may be irrelevant to the MG. The contentious point is therefore one of how the individual parameters should be ordered. What I suggest is that we see through example how they are used, then decide on ordering. We will probably find that there is a dependency here on how we use contexts to represent multimedia. A single-medium context corresponds to one (bidirectional) or two unidirectional H.245 logical channels. There is an issue here: how does the MGC correlate the second logical channel with the first one? Do we end up with a separate context for each H.245 logical channel? A multimedia context corresponds to a number of logical channels, but the correlation rules are simpler: all logical channels associated with the same call (H.323 definition) are grouped together. > -----Original Message----- > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > Sent: Thursday, April 15, 1999 4:37 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.GCP draft uploaded > > I agree with Mike in using H.245 between MGC and MG. SDP is essentially > used > for advertising loosely coupled sessions, so it does not have the > functionality necessary to be considered in H.GCP. Also, H.GCP must re-use > H.323 components whenever possible. > > vineet > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@ATTMAIL.COM] > Sent: Wednesday, April 14, 1999 7:04 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.GCP draft uploaded > > > Bryan, > > I don't know whether this is the right place to comment on the Draft. I > have also > copied some of these comments to the megaco list. > > I would like to see the use of SDP between the MGC and MG added to the > issues list. My understanding is that the symantics and syntax of SDP are > different from H.245OLC. Use of SDP in H.gcp will therefore involve a > reordering > of the information sent in H.245 between endpoints. This will add > transcoding > complexity and latency. In addition, all the features of H.245 I believe > cannot be > presently supported in SDP. For maximum efficiency and flexibility > therefore > I think the mechanism used to convey capabilities should mirror the > semantics > and syntax of H.245OLC. I don't believe there is any extra overhead in > adopting this approach over SDP. The coding used may be different from > PER > or > BER. > > I think this also fits in with the list of H.gcp requirements where it is > stated that > all the features of H.245 should be supported. > > Mike > > ____________________ Begin Original Message > ___________________________ > Date: Tue Apr 13 08:57:37 -0400 1999 > From: internet!VIDEOSERVER.COM!bhill (Bryan Hill) > Subject: H.GCP draft uploaded > To: internet!MAILBAG.INTEL.COM!ITU-SG16 > Content-Type: Text > Content-Length: 367 > > Mr. Okubo, > Please find a version of HGCP.doc and HGCP.zip that I have uploaded into > the > ptel incoming site. These are drafts of the contribution I am preparing > for > Santiago. > > Best Regards, > Bryan Hill > _________________________________________________________ > Bryan Hill > VideoServer Inc. > (781) 505-2159 > bhill(a)videoserver.com <mailto:bhill@videoserver.com>

2 2

Re: H.245 vs. SDP
by Gur Kimchi 16 Apr '99

16 Apr '99

Actually, we can look at this from another angle. For H.GCP, the main protocol suite to interwork with (and work within) is H.323 - not SIP. There is a strong parallel between H.245 and H.GCP as it currently stands, with the exception of the use of SDP. Any effort to ignore H.323 interworking in this group will have the same effect as ignoring SIP in MMUSIC ;-) The following are simple to map between ISUP-over-IP/GCP and H.225/H.245 systems: Function H.245 H.GCP (Megaco Design Group Draft) ------------------------------------------------------------------------ Capabilities Exchange CapsExchange Audit Connection Creation OpenLogicalChannel Add Connection Modification ReplacmentFor OLC Modify Connection Deletion CloseLogicalChannel Subtract Connection Moving ReplacmentFor OLC Move So it is simple to have a Gateway between the two models. We can extrapolate further as we could actually look at H.GCP as doing the same things as H.245 - think of it as a text based alternative to H.245, so we can imagine the following models: current SIP --> future SIP | current 323 --> future 323 +--------------------+---------------+---------------+--------------- +---------------+ | service signalling | SIP | SIP | Annex G | Annex G | +--------------------+---------------+---------------+ ---------------+---------------+ | call signalling | SIP | SIP | H.225/Q.931 | H.225/Q.931 | +--------------------+---------------+---------------+ ---------------+---------------+ | connection control | none | GCP | H.245 | GCP | +--------------------+---------------+---------------+ ---------------+---------------+ | media transmission | RTP/RTCP | RTP/RTCP | RTP/RTCP | RTP/RTCP | +--------------------+---------------+---------------+ ---------------+---------------+ Further, H.GCP after all is just a method to decompose gateways, nothing else, so it will be used to construct logical gatways. These gatways MUST interoperate with any other H.323 host - and they cannot when using SDP. +--------------------+ +--------------------+ | MGC |<---245-->| | +--------------------+ | | | | | GCP | Simple Gateway | | | | +--------------------+ | | | MG | | | +--------------------+ +--------------------+ SDP is just not expressive enough for the products many of us are trying to build. Like or not, the mutex and simultaneous capabilities descriptors in H.245 are there for a purpose - as many systems have limitations that need to be expressed. having to design MG hardware to cope with SDP limitations is not the correct answer. A possible solution is create an ASN.1 Text Encoding Rules (TER? I seem to remember some old work that called this NER) for H.245 that will create tables of structure.name=value pairs. This will allow people to build systems with practically no ASN compilers, and allow simple over-the-wire debugging. This H.245 encoding in TER should be used in H.GCP instead of SDP. Bottom line? We can build SDP to H.245 translators, but there is no way to build full H.245 to SDP translators - SDP is just too limited. I hope that at the end of this difficult, and sometimes painful exercise of decomposing the gateway we dont find ourselves designing a less-capabile gateway then what we had before... I am afraid MMUSIC will come to the same conclusion at some point, and will have to invent a new SDP that allows multi-dimensional (maybe with AND/OR/NOT qualifiers) - but this is clearly beyond the scope, and schedule, of the H.GCP work. - gur ______________________________________________________________________ Gur Kimchi Corporate Director, Advance Technologies, Research and Standards VocalTec Communications Ltd web: http://www.vocaltec.com -------- On 04/16/99 03:50 PM GMT Mike Buckley <mikebuckley(a)ATTMAIL.COM> wrote: Thanks for the clarification Tom. This is exactly what I meant. I agree that caps exchange will generally be a registration process. However I would pose a question whether there might not be a need for a caps exchange after registration to identify resources temporarily unavailable (traffic loading etc) or unavailable in a specific set of circumstances. Also is there a role for a caps exchange to change parameters during a session? This might be particularly important in multimedia situations. Mike ____________________ Begin Original Message ___________________________ Date: Fri Apr 16 09:24:57 -0400 1999 From: internet!NORTELNETWORKS.COM!taylor (Tom-PT Taylor) Subject: H.245 vs. SDP To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO Content-Type: Generic-Text Content-Length: 4210 I would like to clarify the issue of H.245 vs. SDP. First off, what we are talking about here is NOT capability negotiation. The latter is handled by signalling between MGCs. A given MGC obtains the information needed to support its end of the negotiation through use of the Audit command. Megaco/H.GCP has the action to ensure that responses to Audit commands convey the necessary information. That said, the question becomes one of SDP vs. the H.245 OpenLogicalChannel (OLC) and OLC Ack structures. I think what Mike is saying is that there are two issues in this discussion: content, and ordering of that content. On content, I think we can get general agreement that if the H.245 OLC can request something, the Media Gateway control protocol should be able to propagate that request to the MG. Thus there is no argument in general over content, leaving aside housekeeping items like the H.245 logical channel number which may be irrelevant to the MG. The contentious point is therefore one of how the individual parameters should be ordered. What I suggest is that we see through example how they are used, then decide on ordering. We will probably find that there is a dependency here on how we use contexts to represent multimedia. A single-medium context corresponds to one (bidirectional) or two unidirectional H.245 logical channels. There is an issue here: how does the MGC correlate the second logical channel with the first one? Do we end up with a separate context for each H.245 logical channel? A multimedia context corresponds to a number of logical channels, but the correlation rules are simpler: all logical channels associated with the same call (H.323 definition) are grouped together. > -----Original Message----- > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > Sent: Thursday, April 15, 1999 4:37 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.GCP draft uploaded > > I agree with Mike in using H.245 between MGC and MG. SDP is essentially > used > for advertising loosely coupled sessions, so it does not have the > functionality necessary to be considered in H.GCP. Also, H.GCP must re-use > H.323 components whenever possible. > > vineet > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@ATTMAIL.COM] > Sent: Wednesday, April 14, 1999 7:04 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.GCP draft uploaded > > > Bryan, > > I don't know whether this is the right place to comment on the Draft. I > have also > copied some of these comments to the megaco list. > > I would like to see the use of SDP between the MGC and MG added to the > issues list. My understanding is that the symantics and syntax of SDP are > different from H.245OLC. Use of SDP in H.gcp will therefore involve a > reordering > of the information sent in H.245 between endpoints. This will add > transcoding > complexity and latency. In addition, all the features of H.245 I believe > cannot be > presently supported in SDP. For maximum efficiency and flexibility > therefore > I think the mechanism used to convey capabilities should mirror the > semantics > and syntax of H.245OLC. I don't believe there is any extra overhead in > adopting this approach over SDP. The coding used may be different from > PER > or > BER. > > I think this also fits in with the list of H.gcp requirements where it is > stated that > all the features of H.245 should be supported. > > Mike > > ____________________ Begin Original Message > ___________________________ > Date: Tue Apr 13 08:57:37 -0400 1999 > From: internet!VIDEOSERVER.COM!bhill (Bryan Hill) > Subject: H.GCP draft uploaded > To: internet!MAILBAG.INTEL.COM!ITU-SG16 > Content-Type: Text > Content-Length: 367 > > Mr. Okubo, > Please find a version of HGCP.doc and HGCP.zip that I have uploaded into > the > ptel incoming site. These are drafts of the contribution I am preparing > for > Santiago. > > Best Regards, > Bryan Hill > _________________________________________________________ > Bryan Hill > VideoServer Inc. > (781) 505-2159 > bhill(a)videoserver.com <mailto:bhill@videoserver.com>

1 0

Re: redundant, conflicting multirate indications
by Paul Long 16 Apr '99

16 Apr '99

Bob, But that's not what H.225.0 says. 7.2.2.1/H.225.0v2: Extension bit for octet #4 (bit 8) - Shall be set to '0' if the information transfer rate is set to 'multirate'; shall be set to '1' otherwise. So it indicates whether the octet-4 rate field is set to multirate, which in turn implies that octet 4.1 is present, according to Q.931. It does not directly indicate whether octet 4.1 is present, regardless of what Q.931 says. That's why, IMO, this normative text in 7.2.2.1 is needlessly redundant and error prone, as I found out at the interop. Therefore, the only correct encodings are: extension bit: 0, rate: multirate, octet 4.1 present and extension bit: 1, rate: not multirate, octet 4.1 not present In particular, the encoding which I encountered at the interop, extension bit: 1, rate: multirate, octet 4.1 present is definitely not correct. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Callaghan, Robert [SMTP:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Friday, April 16, 1999 7:26 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: redundant, conflicting multirate indications Paul, There appears to be a misunderstanding as to the meaning of "extension bit." For all of the Q.931 coded elements, the extension bit set to zero indicates that the octet is extended. If set to one, the octet is not extended. Section 7.2.2.2/H225.0v2 states that the extension bit of octet 4 is set to zero for when multi-rate is present. This only means that the multirate octet (4.1) is present. Or as an inverse, is the bit is set to one, then octet 4.1 may not be present. This does not mean, in itself, that multirate is not present. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information & Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: Friday, April 16, 1999 12:03 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: redundant, conflicting multirate indications Why does 7.2.2.1/H.225.0v2 say that the extension bit of octet 4 in bearer capabilities indicates whether the information-transfer-rate field is set to multirate? Isn't this redundant? It caused me a problem at the last interop, because someone sent a Setup message with the extension bit indicating that it _was not_ multirate and the rate field indicating that it _was_ multirate. My EP looked at the extension bit instead of the rate field--they should agree, shouldn't they?--and assumed that octet 4.1 was not present when in fact it was. This caused a decode error decoding what it thought was octet 5 but was in fact octet 4.1. I have changed the code so that it now looks at the rate field but was just wondering if anyone had a better understanding of this situation. Paul Long Smith Micro Software, Inc.

1 0

H.245 vs. SDP
by Tom-PT Taylor 16 Apr '99

16 Apr '99

I would like to clarify the issue of H.245 vs. SDP. First off, what we are talking about here is NOT capability negotiation. The latter is handled by signalling between MGCs. A given MGC obtains the information needed to support its end of the negotiation through use of the Audit command. Megaco/H.GCP has the action to ensure that responses to Audit commands convey the necessary information. That said, the question becomes one of SDP vs. the H.245 OpenLogicalChannel (OLC) and OLC Ack structures. I think what Mike is saying is that there are two issues in this discussion: content, and ordering of that content. On content, I think we can get general agreement that if the H.245 OLC can request something, the Media Gateway control protocol should be able to propagate that request to the MG. Thus there is no argument in general over content, leaving aside housekeeping items like the H.245 logical channel number which may be irrelevant to the MG. The contentious point is therefore one of how the individual parameters should be ordered. What I suggest is that we see through example how they are used, then decide on ordering. We will probably find that there is a dependency here on how we use contexts to represent multimedia. A single-medium context corresponds to one (bidirectional) or two unidirectional H.245 logical channels. There is an issue here: how does the MGC correlate the second logical channel with the first one? Do we end up with a separate context for each H.245 logical channel? A multimedia context corresponds to a number of logical channels, but the correlation rules are simpler: all logical channels associated with the same call (H.323 definition) are grouped together. > -----Original Message----- > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > Sent: Thursday, April 15, 1999 4:37 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.GCP draft uploaded > > I agree with Mike in using H.245 between MGC and MG. SDP is essentially > used > for advertising loosely coupled sessions, so it does not have the > functionality necessary to be considered in H.GCP. Also, H.GCP must re-use > H.323 components whenever possible. > > vineet > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@ATTMAIL.COM] > Sent: Wednesday, April 14, 1999 7:04 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.GCP draft uploaded > > > Bryan, > > I don't know whether this is the right place to comment on the Draft. I > have also > copied some of these comments to the megaco list. > > I would like to see the use of SDP between the MGC and MG added to the > issues list. My understanding is that the symantics and syntax of SDP are > different from H.245OLC. Use of SDP in H.gcp will therefore involve a > reordering > of the information sent in H.245 between endpoints. This will add > transcoding > complexity and latency. In addition, all the features of H.245 I believe > cannot be > presently supported in SDP. For maximum efficiency and flexibility > therefore > I think the mechanism used to convey capabilities should mirror the > semantics > and syntax of H.245OLC. I don't believe there is any extra overhead in > adopting this approach over SDP. The coding used may be different from > PER > or > BER. > > I think this also fits in with the list of H.gcp requirements where it is > stated that > all the features of H.245 should be supported. > > Mike > > ____________________ Begin Original Message > ___________________________ > Date: Tue Apr 13 08:57:37 -0400 1999 > From: internet!VIDEOSERVER.COM!bhill (Bryan Hill) > Subject: H.GCP draft uploaded > To: internet!MAILBAG.INTEL.COM!ITU-SG16 > Content-Type: Text > Content-Length: 367 > > Mr. Okubo, > Please find a version of HGCP.doc and HGCP.zip that I have uploaded into > the > ptel incoming site. These are drafts of the contribution I am preparing > for > Santiago. > > Best Regards, > Bryan Hill > _________________________________________________________ > Bryan Hill > VideoServer Inc. > (781) 505-2159 > bhill(a)videoserver.com <mailto:bhill@videoserver.com>

1 0

Recall: redundant, conflicting multirate indications
by Callaghan, Robert 16 Apr '99

16 Apr '99

Callaghan, Robert would like to recall the message, "redundant, conflicting multirate indications".

1 0

Re: redundant, conflicting multirate indications
by Callaghan, Robert 16 Apr '99

16 Apr '99

Paul, There appears to be a misunderstanding as to the meaning of "extension bit." For all of the Q.931 coded elements, the extension bit set to zero indicates that the octet is extended. If set to one, the octet is not extended. Section 7.2.2.2/H225.0v2 states that the extension bit of octet 4 is set to zero for when multi-rate is present. This only means that the multirate octet (4.1) is present. Or as an inverse, is the bit is set to one, then octet 4.1 may not be present. This does not mean, in itself, that multirate is not present. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information & Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: Friday, April 16, 1999 12:03 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: redundant, conflicting multirate indications Why does 7.2.2.1/H.225.0v2 say that the extension bit of octet 4 in bearer capabilities indicates whether the information-transfer-rate field is set to multirate? Isn't this redundant? It caused me a problem at the last interop, because someone sent a Setup message with the extension bit indicating that it _was not_ multirate and the rate field indicating that it _was_ multirate. My EP looked at the extension bit instead of the rate field--they should agree, shouldn't they?--and assumed that octet 4.1 was not present when in fact it was. This caused a decode error decoding what it thought was octet 5 but was in fact octet 4.1. I have changed the code so that it now looks at the rate field but was just wondering if anyone had a better understanding of this situation. Paul Long Smith Micro Software, Inc.

1 0

AW: redundant, conflicting multirate indications
by Ernst Horvath 16 Apr '99

16 Apr '99

Mr. Long, the information in 7.2.2.1/H.225.0 conflicts with Q.931 and in my opinion should be changed to align with Q.931. In Q.931 the extension bit of octet 4 indicates the presence of octets 4a/4b, _not_ of octet 4.1. The presence of octet 4.1 depends only on the rate field of octet 4. I propose to fix this obvious mistake in V3 of H.225.0 and also put something into the implementors guide for V2. Ernst Horvath Siemens AG Email: ernst.horvath(a)siemens.at -----Ursprüngliche Nachricht----- Von: Plong [SMTP:Plong@SMITHMICRO.COM] Gesendet am: Freitag, 16. April 1999 06:03 An: ITU-SG16 Cc: Plong Betreff: redundant, conflicting multirate indications Why does 7.2.2.1/H.225.0v2 say that the extension bit of octet 4 in bearer capabilities indicates whether the information-transfer-rate field is set to multirate? Isn't this redundant? It caused me a problem at the last interop, because someone sent a Setup message with the extension bit indicating that it _was not_ multirate and the rate field indicating that it _was_ multirate. My EP looked at the extension bit instead of the rate field--they should agree, shouldn't they?--and assumed that octet 4.1 was not present when in fact it was. This caused a decode error decoding what it thought was octet 5 but was in fact octet 4.1. I have changed the code so that it now looks at the rate field but was just wondering if anyone had a better understanding of this situation. Paul Long Smith Micro Software, Inc. << Datei: redundant, conflicting multirate indications.TXT >>

1 0

redundant, conflicting multirate indications
by Paul Long 16 Apr '99

16 Apr '99

Why does 7.2.2.1/H.225.0v2 say that the extension bit of octet 4 in bearer capabilities indicates whether the information-transfer-rate field is set to multirate? Isn't this redundant? It caused me a problem at the last interop, because someone sent a Setup message with the extension bit indicating that it _was not_ multirate and the rate field indicating that it _was_ multirate. My EP looked at the extension bit instead of the rate field--they should agree, shouldn't they?--and assumed that octet 4.1 was not present when in fact it was. This caused a decode error decoding what it thought was octet 5 but was in fact octet 4.1. I have changed the code so that it now looks at the rate field but was just wondering if anyone had a better understanding of this situation. Paul Long Smith Micro Software, Inc.

1 0

Re: H.GCP draft uploaded
by Kumar, Vineet 15 Apr '99

15 Apr '99

I agree with Mike in using H.245 between MGC and MG. SDP is essentially used for advertising loosely coupled sessions, so it does not have the functionality necessary to be considered in H.GCP. Also, H.GCP must re-use H.323 components whenever possible. vineet -----Original Message----- From: Mike Buckley [mailto:mikebuckley@ATTMAIL.COM] Sent: Wednesday, April 14, 1999 7:04 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.GCP draft uploaded Bryan, I don't know whether this is the right place to comment on the Draft. I have also copied some of these comments to the megaco list. I would like to see the use of SDP between the MGC and MG added to the issues list. My understanding is that the symantics and syntax of SDP are different from H.245OLC. Use of SDP in H.gcp will therefore involve a reordering of the information sent in H.245 between endpoints. This will add transcoding complexity and latency. In addition, all the features of H.245 I believe cannot be presently supported in SDP. For maximum efficiency and flexibility therefore I think the mechanism used to convey capabilities should mirror the semantics and syntax of H.245OLC. I don't believe there is any extra overhead in adopting this approach over SDP. The coding used may be different from PER or BER. I think this also fits in with the list of H.gcp requirements where it is stated that all the features of H.245 should be supported. Mike ____________________ Begin Original Message ___________________________ Date: Tue Apr 13 08:57:37 -0400 1999 From: internet!VIDEOSERVER.COM!bhill (Bryan Hill) Subject: H.GCP draft uploaded To: internet!MAILBAG.INTEL.COM!ITU-SG16 Content-Type: Text Content-Length: 367 Mr. Okubo, Please find a version of HGCP.doc and HGCP.zip that I have uploaded into the ptel incoming site. These are drafts of the contribution I am preparing for Santiago. Best Regards, Bryan Hill _________________________________________________________ Bryan Hill VideoServer Inc. (781) 505-2159 bhill(a)videoserver.com <mailto:bhill@videoserver.com>

1 0