April 1999 - sg16-avd - lists.packetizer.com

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

17 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 17 Apr '99

17 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

h.341 questions
by Göran Larsson 15 Apr '99

15 Apr '99

SG16 members, I have been reading the Proposed Recommendation H.341 (December 1998)and have now some questions. 1) I want to specify a PRI-interface to PSTN in the Gateway. Which MIB's or part of MIB' do I use ? Could or should the H.320 MIB (or parts of) be used in any way (together with the H.320 parts in the H.323 Gateway MIB) ? or should only the PSTN parts of the H.323 Gateway MIB be used ? or is the PRI part not covered in the H.341 ? 2) How do I specify the "real" PRI-interface e.g. channels ? is the intension of H.341 to be used with other MIB's, e.g. RFC2127 and RFC2495 to specify the "real" PRI interface ? 3) In the H.323 Gateway MIB there is a H323GwCapabilitiesH320Table. This table contain an attribut called H323GwCapabilitiesH320CapsTableIndex which point out an table in the H.320 Entity MIB. What is the relation between these tables ? Do you have one row of the H323GwCapabilitiesH320Table and only one row in the H320CapsTable or can you have many rows of the H323GwCapabilitiesH320Table, each pointing to a unique row in the H320CapsTable or ? The text describing the H320CapsTable says that "The number of rows will be equal to the number of H320 entities in the MCU and the H320/H323 Gateway". The relation between these tables are not clear to me. 4) Chapter 6.2 H.323 Systems. The text says "In an H.320/H.323 gateway, both the H.320 Entity and Terminal MIBs are required". The text in chapter 8.2 H.320 indicate something else, i.e. that only the H.320 Entity MIB is required. Is that a correct interpretation ? 5) I am missing some kind of Entity Relation or object model of each entity. e.g the Gateway. Something that describes the relation between the MIBs and tables (e.g. ports, cennections and calls). Do the SG16 have the intenstion to add something like that to the Recommendation ? Regards Göran Larsson, Telia ProSoft Sundsvall, Sweden phone : +46 60 144681 e-mail : goran.c.larsson(a)telia.se

1 0

Re: e164 vs. partyNumber aliases
by Alexander Rovny 15 Apr '99

15 Apr '99

Maybe the idea was as following. The Endpoint itself may avoid parsing or somehow handling any prefixes in the dialed number but may just pass the E164 alias as it is to its Gatekeeper. The latter may avoid replacing the prefixes with ones specific to the destination (say) gateway but may translate the alias into a partyNumber one and return it in ACF. So E164 is understood as a locally valid alias, and partyNumber as an alias to be propagated worldwide. Alexander Rovny MD Information Systems

1 0

Re: e164 vs. partyNumber aliases
by Chris Purvis 15 Apr '99

15 Apr '99

Paul, My feeling would be that as an endpoint making calls, you will probably only be dealing with dialled numbers, and will therefore use the e164 field. When you're registering with a gatekeeper, however, you may need to do different. For example, I have here an internal phone number within Madge (31359), and a DDI number (+44 1753 661 359). I could see a sensible way of modelling that situation as being for my endpoint to register a PrivatePartyNumber of the former and a PublicPartyNumber of that latter. The gatekeeper then needs to cope with the difference between the two, and who dials what to get hold of you. If you use only the e164 number field, you either register one or the other (and expect the gatekeeper to translate), or register both. The advantage of differentiating them in some way (either using typed numbers or letting the gatekeeper "invent" another number for you) is that (particularly in the world of H.225.0 Annex G) the gatekeeper will probably only publicise public numbers to third parties (after all, a four or five digit number can't be expected to identify individuals uniquely if the scope is larger than a single organisation). If, then, you accept that such differentiation is useful, that means you're asking extra intelligence within your gatekeeper. It may make it "easier" for gatekeepers to have that extra intelligence if you register typed, rather than dialled, numbers. Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis(a)madge.com > -----Original Message----- > From: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: 14 April 1999 6:57 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: e164 vs. partyNumber aliases > > > Okay, but what is the status of the e164 alias? For example, > if a user enters > a "telephone number" at a v1 EP, it must be provided as an > e164 alias. Will > all other entities continue to recognize this as a telephone > number? Now if a > user does the same thing at a v2 EP, can the number be > provided as an e164 > alias _or_ a partyNumber? Will all entities continue to > support both types of > aliases, or is e164 deprecated as of v2? As an EP vendor, I'd > really hate to > require the user to indicate whether the number they just > entered is an "e164 > alias" or a "party number." Yucko... Maybe, just to be safe, > the number should > be provided in both forms, but I think some entities get confused when > confronted with multiple aliases, or at least the semantics > of such a thing is > ambiguous. > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Callaghan, Robert > [SMTP:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Wednesday, April 14, 1999 12:14 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: e164 vs. partyNumber aliases > > Paul, > > The E164 alias, in use, is the user dialed number not > a structured > E.164 > address. The partyNumber is the structured E.164 or > Private Number. > > 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: Wednesday, April 14, 1999 12:38 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: e164 vs. partyNumber aliases > > > What is the difference between an e164 alias and a > partyNumber alias? > Was > e164 > found lacking, and does partyNumber now supercede it? > Are we supposed > to > stop > using e164? If not, how do we decide which form to use? > > Paul Long > Smith Micro Software, Inc. >

1 0

Re: H.320 to H.323 Gateways: Will They Decompose?
by Paul Long 15 Apr '99

15 Apr '99

I agree. H.324 does not have the cache and is not experiencing the same intense interest of H.323, but it still lives, and the number of vendors is stable. Plus, across the PSTN, it blows the doors off H.323. :-) Paul Long Smith Micro Software, Inc. -----Original Message----- From: Christian Groves [SMTP:epachg@EPA.ERICSSON.SE] Sent: Wednesday, April 14, 1999 8:23 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.320 to H.323 Gateways: Will They Decompose? G'Day Ami and Tom, There has been some initial disucssion in the 3rd generation mobile projects (ie.UMTS) regarding the usage of H.324 therefore I think its too early to preclude H.324 from MEGACOP discussion. So I think that it should definately be supported in the scope of MEGACOP. Cheers, Christian Ami Amir wrote: > > Tom, > > Without going into specific product plans, it is clear that for deployments > that want to support both voice AND H.320 - deployment of "video only" > gateways does not make any sense, and the same gateway needs to support > both functions. > > So, if voice will opt for decomposition, it should find a way to > accommodate the video/data side. BTW - H.324 "died" because there was no > real application/network that supported it well. It seems to me that in the > new networks (e.g. ADSL or Cable or wireless local loop) it might still be > useful. Should we support it in Megacop? > > Ami > > -----Original Message----- > From: Tom-PT Taylor [SMTP:taylor@nortelnetworks.com] > Sent: Friday, April 09, 1999 9:57 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: H.320 to H.323 Gateways: Will They Decompose? > > This is addressed to the experts of Study Group 16, but has impact on the > priorities of work both for Megaco and for H.GCP. The question, which I > raised obliquely in a previous exchange on co-location of H.245 signalling > with the Media Gateway function, is whether any vendor will actually create > a decomposed H.320-to-H.323 Gateway. If not, we can stop worrying about > how > to accommodate H.320 in the Media Gateway control protocol. > > Tom Taylor > E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) > Tel.: +1 613 736 0961 (ESN 396-1490) > FAX: same number by prior arrangement (manual answer).

1 0

H.GCP draft uploaded
by Bryan Hill 15 Apr '99

15 Apr '99

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 1

Re: H.320 to H.323 Gateways: Will They Decompose?
by Ami Amir 15 Apr '99

15 Apr '99

Tom, Without going into specific product plans, it is clear that for deployments that want to support both voice AND H.320 - deployment of "video only" gateways does not make any sense, and the same gateway needs to support both functions. So, if voice will opt for decomposition, it should find a way to accommodate the video/data side. BTW - H.324 "died" because there was no real application/network that supported it well. It seems to me that in the new networks (e.g. ADSL or Cable or wireless local loop) it might still be useful. Should we support it in Megacop? Ami -----Original Message----- From: Tom-PT Taylor [SMTP:taylor@nortelnetworks.com] Sent: Friday, April 09, 1999 9:57 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.320 to H.323 Gateways: Will They Decompose? This is addressed to the experts of Study Group 16, but has impact on the priorities of work both for Megaco and for H.GCP. The question, which I raised obliquely in a previous exchange on co-location of H.245 signalling with the Media Gateway function, is whether any vendor will actually create a decomposed H.320-to-H.323 Gateway. If not, we can stop worrying about how to accommodate H.320 in the Media Gateway control protocol. Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 736 0961 (ESN 396-1490) FAX: same number by prior arrangement (manual answer).

2 1

Re: e164 vs. partyNumber aliases
by Callaghan, Robert 14 Apr '99

14 Apr '99

Paul, It may be proper for to have the terminal parse the user dialed number and place the structured results in the partyNumber. And then to also place the user dialed number in the E164 address. This would give the best possible results. However, H.323 should be modified to require the use of partyNumber first, if present, and use E164 alias. 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: Wednesday, April 14, 1999 1:57 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: e164 vs. partyNumber aliases Okay, but what is the status of the e164 alias? For example, if a user enters a "telephone number" at a v1 EP, it must be provided as an e164 alias. Will all other entities continue to recognize this as a telephone number? Now if a user does the same thing at a v2 EP, can the number be provided as an e164 alias _or_ a partyNumber? Will all entities continue to support both types of aliases, or is e164 deprecated as of v2? As an EP vendor, I'd really hate to require the user to indicate whether the number they just entered is an "e164 alias" or a "party number." Yucko... Maybe, just to be safe, the number should be provided in both forms, but I think some entities get confused when confronted with multiple aliases, or at least the semantics of such a thing is ambiguous. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Callaghan, Robert [SMTP:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Wednesday, April 14, 1999 12:14 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: e164 vs. partyNumber aliases Paul, The E164 alias, in use, is the user dialed number not a structured E.164 address. The partyNumber is the structured E.164 or Private Number. 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: Wednesday, April 14, 1999 12:38 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: e164 vs. partyNumber aliases What is the difference between an e164 alias and a partyNumber alias? Was e164 found lacking, and does partyNumber now supercede it? Are we supposed to stop using e164? If not, how do we decide which form to use? Paul Long Smith Micro Software, Inc.

2 1

Re: e164 vs. partyNumber aliases
by Paul Long 14 Apr '99

14 Apr '99

Okay, but what is the status of the e164 alias? For example, if a user enters a "telephone number" at a v1 EP, it must be provided as an e164 alias. Will all other entities continue to recognize this as a telephone number? Now if a user does the same thing at a v2 EP, can the number be provided as an e164 alias _or_ a partyNumber? Will all entities continue to support both types of aliases, or is e164 deprecated as of v2? As an EP vendor, I'd really hate to require the user to indicate whether the number they just entered is an "e164 alias" or a "party number." Yucko... Maybe, just to be safe, the number should be provided in both forms, but I think some entities get confused when confronted with multiple aliases, or at least the semantics of such a thing is ambiguous. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Callaghan, Robert [SMTP:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Wednesday, April 14, 1999 12:14 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: e164 vs. partyNumber aliases Paul, The E164 alias, in use, is the user dialed number not a structured E.164 address. The partyNumber is the structured E.164 or Private Number. 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: Wednesday, April 14, 1999 12:38 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: e164 vs. partyNumber aliases What is the difference between an e164 alias and a partyNumber alias? Was e164 found lacking, and does partyNumber now supercede it? Are we supposed to stop using e164? If not, how do we decide which form to use? Paul Long Smith Micro Software, Inc.

1 0

WG: H.323 Implementers Guide Edits
by Karl.Klaghofer＠ICN.SIEMENS.DE 14 Apr '99

14 Apr '99

Jim, I think we have found an error in the Implementer's Guide. The change for Section 7.2.2 of H.323 has the following new paragraph apparently added to 7.2.2 although this paragraph is already part of the H.323v2 Standard within this clause 7.2.2. Was the intention to copy this standard paragraph to the new section 7.2.2.1 "use of lightweight RRQ" ? - then we can delete the para within clause 7.2.2 in the impl guide and just keep the para below 7.2.2.1. ...." An endpoint's registration with a Gatekeeper may have a finite life. An endpoint may request a timeToLive in the RRQ message to the Gatekeeper. The Gatekeeper may respond with an RCF containing the same timeToLive or a shorter timeToLive. After this time, the registration shall be expired. The timeToLive is expressed in seconds. Prior to the expiration time, the endpoint may send an RRQ message having the keepAlive bit set. The keep alive RRQ may include a minimum amount of information as described in H.225.0. The keep alive RRQ shall reset the time to live timer in the Gatekeeper, allowing the registration to be extended. After the expiration time, the endpoint must re-register with a Gatekeeper using a full RRQ message. ...." Regards, Karl Klaghofer, Siemens AG karl.klaghofer(a)icn.siemens.de > -----Ursprüngliche Nachricht----- > Von: Jim Toga [SMTP:jim.toga@metatel.com] > Gesendet am: Freitag, 9. April 1999 15:50 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: H.323 Implementers Guide Edits > > Greetings, > > After some delay, I have completed the edits coming out of the Monterey > meeting for the Implementers Guide. Please review the changes and verify > that everything is as expected. > > I have incorporated (I believel) all of the relevent text mentioned in the > Meeting report namely: > APCs 1511,1512, 1520, 1522, 1533, 1506, and TDs 10, 14, 33. > > If I do not have any comments back by 4/16/99 then I will integrate these > changes with the complete document in preparation for the Chile meeting. > > Best Regards, > jimt.

2 1

Re: e164 vs. partyNumber aliases
by Callaghan, Robert 14 Apr '99

14 Apr '99

Santo, This is an interesting problem. However, as the E164 alias is a user dialed number, it will include such thing as "011" for international calls. However, if the call uses a foreign gateway, the gateway will not understand "011" as it is expecting "00" to indicate an international call so it will treat "0" as a national call and try to send the call to "11+". The structured values in partyNumber indication the unique number without any identification or routing information. Therefore a number indicated as an international number is valid anywhere in the world. 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: Santo Wiryaman [mailto:swiryaman@VIDEOSERVER.COM] Sent: Wednesday, April 14, 1999 1:13 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: e164 vs. partyNumber aliases I like to see e164 alias being used. In order for an EP to send the new V2 aliases, it has to know that the destination is a V2 or higher. How does the caller know the callee is V2 or higher? Any thoughts? ---------------------------------------- Santo Wiryaman VideoServer, Inc. Phone:+1.781.505.2348 Fax:+1.781.505.2101 email:swiryaman@videoserver.com http://www.videoserver.com > -----Original Message----- > From: Paul Long [SMTP:Plong@SMITHMICRO.COM] > Sent: Wednesday, April 14, 1999 12:38 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: e164 vs. partyNumber aliases > > What is the difference between an e164 alias and a partyNumber alias? Was > e164 > found lacking, and does partyNumber now supercede it? Are we supposed to > stop > using e164? If not, how do we decide which form to use? > > Paul Long > Smith Micro Software, Inc.

1 0

Re: e164 vs. partyNumber aliases
by Callaghan, Robert 14 Apr '99

14 Apr '99

Paul, The E164 alias, in use, is the user dialed number not a structured E.164 address. The partyNumber is the structured E.164 or Private Number. 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: Wednesday, April 14, 1999 12:38 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: e164 vs. partyNumber aliases What is the difference between an e164 alias and a partyNumber alias? Was e164 found lacking, and does partyNumber now supercede it? Are we supposed to stop using e164? If not, how do we decide which form to use? Paul Long Smith Micro Software, Inc.

1 0

Re: e164 vs. partyNumber aliases
by Santo Wiryaman 14 Apr '99

14 Apr '99

I like to see e164 alias being used. In order for an EP to send the new V2 aliases, it has to know that the destination is a V2 or higher. How does the caller know the callee is V2 or higher? Any thoughts? ---------------------------------------- Santo Wiryaman VideoServer, Inc. Phone:+1.781.505.2348 Fax:+1.781.505.2101 email:swiryaman@videoserver.com http://www.videoserver.com > -----Original Message----- > From: Paul Long [SMTP:Plong@SMITHMICRO.COM] > Sent: Wednesday, April 14, 1999 12:38 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: e164 vs. partyNumber aliases > > What is the difference between an e164 alias and a partyNumber alias? Was > e164 > found lacking, and does partyNumber now supercede it? Are we supposed to > stop > using e164? If not, how do we decide which form to use? > > Paul Long > Smith Micro Software, Inc.

1 0

e164 vs. partyNumber aliases
by Paul Long 14 Apr '99

14 Apr '99

What is the difference between an e164 alias and a partyNumber alias? Was e164 found lacking, and does partyNumber now supercede it? Are we supposed to stop using e164? If not, how do we decide which form to use? Paul Long Smith Micro Software, Inc.

1 0

Coordiantion between IETF and ITU
by Joon Maeng 14 Apr '99

14 Apr '99

Randy, I noticed that you have done an excellent job of informing important activities of other standardization bodies to T1A1. Nowadays, many ITU experts attend IETF meetings as well and many ITU guys are also IETF guys at the worker level. It sounds like we need more than exchanging liaisons between two organizations. I don't have answers for T1A1 but I think it is important to improve the communication between IETF and ITU. I am posting your question to some list servers I know of. IETF and ITU may have addressed what you asked already. If they haven't, I can think of three possible solutions. One is inter-pollinating list servers between two organizations as many as possible. We can suggest Working Group Chairpersons of IETF to subscribe appropriate ITU list servers and Study Group Chairpersons of ITU to do the same thing. The other possibility is to have ITU and IETF management teams get together (they might have done it already) and put a communication structure in place. And the third may be forming an ITU and IETF Inter-pollination Group (IIIG) at the worker level and have each organization submit anything that may affect others to the group. IIIG can be a traffic controller. If ITU is willing to recognize IIIG (or IETF) as a nation, it would be interesting. (there can be negative side effects). Modified and improved version of my third idea may work. Any comments? Regards, Joon --------------------------------------------------------------- Joon Maeng VTEL Corp. phone: 512-437-4567 email: joon_maeng(a)vtel.com --------------------------------------------------------------- randy(a)its.bldrdoc.gov on 04/13/99 06:53:45 PM Please respond to randy(a)its.bldrdoc.gov To: t1a1-internet(a)t1.org cc: (bcc: Joon Maeng/AUS/VTEL) Subject: Fw: Re: H.323 Annex E for Decision in ITU With reference to the comment in the email below, I think serious consideration is needed regarding how better relations with the IETF can be established and improved over time by all interested organizations. Any ideas or suggestions on how T1A1 could help out here? - Randy Bloomfield --- On Tue, 13 Apr 1999 13:33:15 -0700 braden(a)ISI.EDU wrote: *> From end2end-interest-owner(a)ISI.EDU Tue Apr 13 08:50:24 1999 *> Date: Tue, 13 Apr 1999 11:48:33 -0400 (EDT) *> From: Scott Bradner <sob(a)harvard.edu> *> To: chsharp(a)cisco.com, end2end-interest(a)ISI.EDU *> Subject: Re: H.323 Annex E for Decision in ITU *> Sender: owner-end2end-interest(a)ISI.EDU *> Precedence: bulk *> Content-Length: 88 *> X-Lines: 3 *> *> note that this proposal also includes a flow control option for the non-TCP case *> *> Scott *> Scott, How do those ITU guys breathe, living in a vacuum as they do? Bob Braden ---------------End of Original Message-----------------

1 0

Revised-msg(Studygroup 16/D draft uploaded)
by Edgar Martinez 14 Apr '99

14 Apr '99

Please find a version of Tun&H.246.doc and Tun&H.246.zip that I have uploaded into ftp://standard.pictel.com/avc-site/Incoming/ for the washington meeting Apr 21. Summary This contribution discusses a framework for transporting signaling protocols (SS7, TCAP, ISDN, QSIG and DPNSS) over IP packet networks. The framework is referred to as signaling 'backhaul'. The backhaul or tunneling takes place between a Media Gateway (MG) and/or Signaling Gateway (SG), which interfaces between the circuit world (PSTN) and the IP packet world GateKeeper (GK) and a Media Gateway Controller (MGC), which provides call processing. It is referred to as 'backhaul' because the gateway terminates the lower layers of the protocol (i.e. Layer 1 and 2) and backhauls the other layers to the MGC and/or Gatekeeper. Annex A provides a overview how the RAS messages may interwork INAP. Best Regards, Ed Martinez mailto:martinze@cig.mot.com

2 1

Studygroup 16/D draft uploaded
by Edgar Martinez 14 Apr '99

14 Apr '99

Please find a version of HGCP.doc and HGCP.zip that I have uploaded into ftp://standard.pictel.com/avc-site/Incoming/ for the washington meeting Apr 21. Summary This contribution discusses a framework for transporting signaling protocols (SS7, TCAP, ISDN, QSIG and DPNSS) over IP packet networks. The framework is referred to as signaling 'backhaul'. The backhaul or tunneling takes place between a Media Gateway (MG) and/or Signaling Gateway (SG), which interfaces between the circuit world (PSTN) and the IP packet world GateKeeper (GK) and a Media Gateway Controller (MGC), which provides call processing. It is referred to as 'backhaul' because the gateway terminates the lower layers of the protocol (i.e. Layer 1 and 2) and backhauls the other layers to the MGC and/or Gatekeeper. Annex A provides a overview how the RAS messages may interwork INAP. Best Regards, Ed Martinez mailto:martinze@cig.mot.com

1 0

H.246 Annex B
by Karl.Klaghofer＠ICN.SIEMENS.DE 14 Apr '99

14 Apr '99

Can someone point out the status of H.246 Annex B and point me to the current draft ? In the Geneva 9/98 SG16 Meeting, determination of Annex B was deferred. In the subsequent rapporteurs meetings (Torino and Monterey) there were no Annex B contributions. Thanks, Karl ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)icn.siemens.de

1 0

Re: Event reporting (was audio call Thursday: Minutes)
by Brian Rosen 12 Apr '99

12 Apr '99

The MG has to keep the Event -> Termination relationship. If it has to deal with RequestIDs, it's just some storage; it doesn't interpret or deal with it, it just regurgitates it back to the MGC. The MGC has to know all three pieces of information. It generates RequestIDs, and would have to keep the relationship between the RequestID and the EventID and TerminationID. In particular, for each RequestID, it must store the TerminationID and EventID. In that circumstance (the one where you decide RequestID is required), there is no point in TRANSMITTING the TerminationID and the EventID with the Notify; both ends must understand the relationships, and it's a table look-up from RequestID to TerminationID/EventID at the MGC and EventID & TerminationID to RequestID at the MG. Brian > -----Original Message----- > From: Paul Sijben [mailto:sijben@LUCENT.COM] > Sent: Monday, April 12, 1999 5:09 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > What I am going to say may sound like a political compromise > but in fact > isn't. > > Having read the disucssion i see a good reason to do both: > > 1) eventID+terminationID : it is straightforward and relies > on the minimum > of state to be kept and it allows multiple events to be set > in one request. > 2) requestID: it may help you in timing sensitive cases > (although I am not > completely convinced yet). > > Yet, is there any problem in allowing both in a notify message. The > overhead would only be a few bytes in transport and the keeping of the > requestID in the MGW as long as the MGC is interested in an > event. I have > seen no rule against having the best of both worlds. :-) > > Paul > > Flemming Andreasen wrote: > > > > Well, such is the nature of glare - glare resolution is a > different story > > and the MGC may implement whatever policy it wants. > However, if it cannot > > determine the order of events, it becomes rather hard for > it to achieve any > > kind of policy besides randomness. Having the ability to > determine order > > would seem a solid design principle to me. > > > > Going back to lockstep again, it should be noted that without the > > RequestId, you will *always* have to issue a new request in > response to it, > > since you don't know whether the Notify was generated > before or after some > > request had been received - that's hardly a good solution > since you are now > > forced to send more messages than needed and if signals are > not idempotent, > > you may in fact not achieve what you desired. > > > > I still say there are lots of good reasons for a RequestID > - is anybody > > opposed to including this ? > > > > Regards > > > > Flemming > > > > Brian Rosen <brosen(a)eng.fore.com> on 04/09/99 01:32:52 PM > > > > To: "'Flemming Andreasen'" <fandreas(a)telcordia.com> > > cc: Mailing list for parties associated with ITU-T Study Group 16 > > <ITU-SG16(a)mailbag.cps.intel.com> (bcc: Flemming > Andreasen/Bellcore) > > Subject: RE: Event reporting (was audio call Thursday: Minutes) > > > > Suppose the flash hook came .5 ms after the call waiting > > happened. Clearly the intention is to initiate a new call, > > but your email suggests it should connect to the waiting caller. > > > > It seems to me that whichever action the MGC takes on the > > event it can do the same thing with or without the RequestID. > > This is true because all the events we are discussing have > > long response times relative to MG/MGC communication. > > With timestamps (also a suggestion), it could do something > > approximating the right thing all the time with or without > > RequestIDs. > > > > Please note, I liked RequestIDs when they were suggested. > > I still like them, but I can't currently seem to defend them > > very well. > > > > Brian > > > > > -----Original Message----- > > > From: Flemming Andreasen [mailto:fandreas@telcordia.com] > > > Sent: Friday, April 09, 1999 12:58 PM > > > To: Mailing list for parties associated with ITU-T Study Group 16 > > > Cc: Flemming Andreasen; brosen(a)eng.fore.com > > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > > > > > > > > > > Consider the following example: > > > > > > 1. Party A is currently involved in a call with Party B. The > > > active request > > > for A is RA-1 > > > 2. Another call now arrives to A, who happens to subscribe to > > > call-waiting > > > as well as three-way calling. > > > 3a. The MGC decides that since A subscribes to call-waiting, > > > A should hear > > > call-waiting tones so the MGC sends a new request RA-2 to A > > > 3b. At the same time, party A could have decided to put B on > > > hold and place > > > another call. Party A would then generate a flash-hook which > > > results in a > > > Notify (N-x) message being sent to the MGC. > > > > > > Now, if RA-2 arrived at A prior to A generating the > flash-hook, the > > > call-waiting tone would have been played prior to the > > > flash-hook, and the > > > correct glare resolution would probably be for the > incoming call to be > > > connected. > > > > > > On the other hand, if RA-2 arrived at A after A generated the > > > flash-hook, > > > we should probably consider A to attempt to initiate a new > > > call, and the > > > correct glare resolution would probably be for the incoming > > > call to get > > > called-party-busy treatment, and for A to continue with the > > > call attempt. > > > (In this case, the call-waiting tone would actually be played > > > after the > > > flash-hook, so you may even have a need to specify that > "the following > > > request is only to be applied if there is currently no outstanding > > > Notify"). Also note, that if the RA-2 message had been lost, > > > there would no > > > longer be a need for retransmitting it. > > > > > > The only way you can determine the order of events is by > including the > > > request id (I would not favor a transaction-id based > > > approach), and I do > > > believe that order matters in some cases, so you might as > > > well include a > > > solution, especially when it's this simple. We can probably > > > come up with > > > more examples if needed. > > > > > > > > > Regards > > > > > > Flemming > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen <brosen(a)ENG.FORE.COM> on 04/09/99 11:48:08 AM > > > > > > 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: Flemming Andreasen/Bellcore) > > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > > > > > > > > > > You might be right, but I am confused. > > > > > > The simple case of lockstep works. The EventDescriptor is > > > set up with the event, it happens, you get notified, and you > > > send a modify to rearm it. If the event happens again before > > > the rearm, you ignore it. If it happens after, you get > > > another Notify. > > > > > > The only way I see a problem is when you have time order > > > of a Modify; you have a lockstep event "armed", you send down > > > a Modify with a new EventDescriptor, and the event either > > > happens before or after the Modify command is executed. > > > Perhaps you think it's important to know if the event > > > happened before or after the Modify, but I can't come up with > > > a scenario where it matters. If it does, then I agree, you > > > need a tag that is unique to the setting of the > > > EventDescriptor. > > > > > > I do note that you could (theoretically) report the > > > transactionID of the command that set the event. That would > > > make you sent TerminationID, Event Name and TransactionID on > > > the Notify. It would solve the problem. It might be better > > > to use RequestID rather than that. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Flemming Andreasen [mailto:fandreas@telcordia.com] > > > > Sent: Friday, April 09, 1999 10:13 AM > > > > To: Mailing list for parties associated with ITU-T > Study Group 16 > > > > Cc: brosen(a)eng.fore.com; Flemming Andreasen > > > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > > > > > > > > > > > > > > > There is actually a good reason for the RequestID. It > > > > basically enables you > > > > to determine whether a notification was issued before > or after the > > > > reception of a given request for the notification. As an > > > > example where this > > > > is important, consider what we refer to as "lockstep mode". > > > > It essentially > > > > states that a given request can at most generate one Notify, > > > > which implies > > > > that after receiving a Notify you must send down a new > > > > request. Without a > > > > RequestID you cannot determine whether that request has > already been > > > > received or not. This is not only protocol-wise important but > > > > semantically > > > > as well, as your new request may contain instructions to look > > > > for a new set > > > > of events that all of a sudden either became important to > > > > know about, or > > > > you no longer want to hear about. Thus we should keep > the RequestID. > > > > > > > > > > > > Regards > > > > > > > > Flemming Andreasen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen <brosen(a)ENG.FORE.COM> on 04/09/99 08:18:46 AM > > > > > > > > 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: Flemming Andreasen/Bellcore) > > > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > > > > > > > > > > > > > > > As the protocol is currently defined, there is > > > > thus thing we called a RequestID. You supply > > > > a RequestID with the EventDescriptor, and it is > > > > returned by the Notify. A RequestID is a 32 bit > > > > integer. The syntax defines the requestID, and > > > > uses it in the Notify, but does not show it in > > > > the EventDescriptor. That should be fixed, but... > > > > > > > > As I noted, TerminationID + EventName is logically > > > > equivalent to an MGC assigned RequestID if you > > > > can only have one instance of an event on a > > > > termination. Implementation seems to be simple > > > > in either case at both ends. At the MG, storing > > > > the requestID is easy, but not storing is easier. > > > > At the MGC, the RequestID would be a separate table, > > > > but it would have to have TerminationID and > > > > EventName at least implicitly, and probably > > > > explicitly in it. Searching a structure by > > > > TerminationID and then EventName (or the other way > > > > around) is also easy.Thinking about it overnight, if it > > > > really is the same, then it would be best to > > > > eliminate the RequestID artifice and use Termination > > > > ID + EventName. > > > > > > > > At the time, I believed we thought that there were > > > > circumstances where there was not uniqueness. Right > > > > now, I can't see how that can occur. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Chip Sharp [mailto:chsharp@cisco.com] > > > > > Sent: Thursday, April 08, 1999 5:46 PM > > > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > > > Subject: Re: Event reporting (was audio call > Thursday: Minutes) > > > > > > > > > > > > > > > Yes that was my understanding as well. The TerminationID > > > > > would be used to > > > > > associate the event to the termination. Thus the event > > > report would > > > > > contain the Termination ID and the event ID. > > > > > > > > > > Chip > > > > > > > > > > At 02:21 PM 4/8/99 -0700, Rex Coldren wrote: > > > > > >Actually I believe this item was not correctly written. I > > > > > believe the > > > > > >discussion was about how you associate a reported event > > > to a given > > > > > >Termination. There was talk that notifications come > back with a > > > > > >RequestID, which must be somehow associated to a Termination. > > > > > >Paul suggested using TerminationID directly. > > > > > > > > > > > >Christian Huitema wrote: > > > > > > > > > > > >> > 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 > > > > > >> > > > > > >> Sorry for missing the call, but let's comment on that > > > > > specific point. We > > > > > >> discussed the event reporting model at length during the > > > > > IETF meetings and > > > > > >> in the following week, and I don't beleive that there is > > > > > any advantage in > > > > > >> opening the debate again. > > > > > >> > > > > > >> Termination Id and event names just do not belong to the > > > > > same space. > > > > > >> Terminations are defined on a per MG basis; > events are defined > > > > > >> independently of the MG, and in many cases > independently of the > > > > > >> termination class. > > > > > >> > > > > > >> The current notifications identify both the termination on > > > > > which the event > > > > > >> was observed and the name of the event. There is a lot of > > > > > experience to > > > > > >> show that this is a very efficient decomposition, and I > > > > > don't see any > > > > > >> reason whatsoever for ditching the experience in favor of > > > > > an unproven > > > > > >> theoretical design. > > > > > >> > > > > > >> -- > > > > > >> Christian Huitema > > > > > >> ------------------------------ > > > > > >> Please note my new address: huitema(a)research.telcordia.com > > > > > >> http://www.telcordia.com/ > > > > > > > > > > > > > > > > > -------------------------------------------------- > > > > > Chip Sharp voice: +1 (919) 851-2085 > > > > > Cisco Systems Consulting Eng. - Telco > > > > > Reality - Love it or Leave it. > > > > > -------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Paul Sijben Telno:+ 31 35 687 4774 Fax:+31 35 687 5954 > Lucent Technologies Home telno: +31 33 4557522 > Forward Looking Work e-mail: sijben(a)lucent.com > Huizen, The Netherlands internal http://hzsgp68.nl.lucent.com/ >

1 0

Re: Event reporting (was audio call Thursday: Minutes)
by Flemming Andreasen 12 Apr '99

12 Apr '99

Sounds good to me assuming the structure is something like <terminationID, requestID, event_1, event_2, ..., event_n> since there is no reason to repeat the terminationID (or requestID for that matter) for every event reported in a Notify message. Basically, you simply want to know - which termination generated the event(s), hence the terminationID - which request triggered the detection of the event., hence the requestID - what the event(s) generated are, hence the eventIDs Regards Flemming Paul Sijben <sijben(a)LUCENT.COM> on 04/12/99 05:09:05 AM 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: Flemming Andreasen/Bellcore) Subject: Re: Event reporting (was audio call Thursday: Minutes) What I am going to say may sound like a political compromise but in fact isn't. Having read the disucssion i see a good reason to do both: 1) eventID+terminationID : it is straightforward and relies on the minimum of state to be kept and it allows multiple events to be set in one request. 2) requestID: it may help you in timing sensitive cases (although I am not completely convinced yet). Yet, is there any problem in allowing both in a notify message. The overhead would only be a few bytes in transport and the keeping of the requestID in the MGW as long as the MGC is interested in an event. I have seen no rule against having the best of both worlds. :-) Paul Flemming Andreasen wrote: > > Well, such is the nature of glare - glare resolution is a different story > and the MGC may implement whatever policy it wants. However, if it cannot > determine the order of events, it becomes rather hard for it to achieve any > kind of policy besides randomness. Having the ability to determine order > would seem a solid design principle to me. > > Going back to lockstep again, it should be noted that without the > RequestId, you will *always* have to issue a new request in response to it, > since you don't know whether the Notify was generated before or after some > request had been received - that's hardly a good solution since you are now > forced to send more messages than needed and if signals are not idempotent, > you may in fact not achieve what you desired. > > I still say there are lots of good reasons for a RequestID - is anybody > opposed to including this ? > > Regards > > Flemming > > Brian Rosen <brosen(a)eng.fore.com> on 04/09/99 01:32:52 PM > > To: "'Flemming Andreasen'" <fandreas(a)telcordia.com> > cc: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> (bcc: Flemming Andreasen/Bellcore) > Subject: RE: Event reporting (was audio call Thursday: Minutes) > > Suppose the flash hook came .5 ms after the call waiting > happened. Clearly the intention is to initiate a new call, > but your email suggests it should connect to the waiting caller. > > It seems to me that whichever action the MGC takes on the > event it can do the same thing with or without the RequestID. > This is true because all the events we are discussing have > long response times relative to MG/MGC communication. > With timestamps (also a suggestion), it could do something > approximating the right thing all the time with or without > RequestIDs. > > Please note, I liked RequestIDs when they were suggested. > I still like them, but I can't currently seem to defend them > very well. > > Brian > > > -----Original Message----- > > From: Flemming Andreasen [mailto:fandreas@telcordia.com] > > Sent: Friday, April 09, 1999 12:58 PM > > To: Mailing list for parties associated with ITU-T Study Group 16 > > Cc: Flemming Andreasen; brosen(a)eng.fore.com > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > > > > > Consider the following example: > > > > 1. Party A is currently involved in a call with Party B. The > > active request > > for A is RA-1 > > 2. Another call now arrives to A, who happens to subscribe to > > call-waiting > > as well as three-way calling. > > 3a. The MGC decides that since A subscribes to call-waiting, > > A should hear > > call-waiting tones so the MGC sends a new request RA-2 to A > > 3b. At the same time, party A could have decided to put B on > > hold and place > > another call. Party A would then generate a flash-hook which > > results in a > > Notify (N-x) message being sent to the MGC. > > > > Now, if RA-2 arrived at A prior to A generating the flash-hook, the > > call-waiting tone would have been played prior to the > > flash-hook, and the > > correct glare resolution would probably be for the incoming call to be > > connected. > > > > On the other hand, if RA-2 arrived at A after A generated the > > flash-hook, > > we should probably consider A to attempt to initiate a new > > call, and the > > correct glare resolution would probably be for the incoming > > call to get > > called-party-busy treatment, and for A to continue with the > > call attempt. > > (In this case, the call-waiting tone would actually be played > > after the > > flash-hook, so you may even have a need to specify that "the following > > request is only to be applied if there is currently no outstanding > > Notify"). Also note, that if the RA-2 message had been lost, > > there would no > > longer be a need for retransmitting it. > > > > The only way you can determine the order of events is by including the > > request id (I would not favor a transaction-id based > > approach), and I do > > believe that order matters in some cases, so you might as > > well include a > > solution, especially when it's this simple. We can probably > > come up with > > more examples if needed. > > > > > > Regards > > > > Flemming > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen <brosen(a)ENG.FORE.COM> on 04/09/99 11:48:08 AM > > > > 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: Flemming Andreasen/Bellcore) > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > > > > > You might be right, but I am confused. > > > > The simple case of lockstep works. The EventDescriptor is > > set up with the event, it happens, you get notified, and you > > send a modify to rearm it. If the event happens again before > > the rearm, you ignore it. If it happens after, you get > > another Notify. > > > > The only way I see a problem is when you have time order > > of a Modify; you have a lockstep event "armed", you send down > > a Modify with a new EventDescriptor, and the event either > > happens before or after the Modify command is executed. > > Perhaps you think it's important to know if the event > > happened before or after the Modify, but I can't come up with > > a scenario where it matters. If it does, then I agree, you > > need a tag that is unique to the setting of the > > EventDescriptor. > > > > I do note that you could (theoretically) report the > > transactionID of the command that set the event. That would > > make you sent TerminationID, Event Name and TransactionID on > > the Notify. It would solve the problem. It might be better > > to use RequestID rather than that. > > > > Brian > > > > > -----Original Message----- > > > From: Flemming Andreasen [mailto:fandreas@telcordia.com] > > > Sent: Friday, April 09, 1999 10:13 AM > > > To: Mailing list for parties associated with ITU-T Study Group 16 > > > Cc: brosen(a)eng.fore.com; Flemming Andreasen > > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > > > > > > > > > > There is actually a good reason for the RequestID. It > > > basically enables you > > > to determine whether a notification was issued before or after the > > > reception of a given request for the notification. As an > > > example where this > > > is important, consider what we refer to as "lockstep mode". > > > It essentially > > > states that a given request can at most generate one Notify, > > > which implies > > > that after receiving a Notify you must send down a new > > > request. Without a > > > RequestID you cannot determine whether that request has already been > > > received or not. This is not only protocol-wise important but > > > semantically > > > as well, as your new request may contain instructions to look > > > for a new set > > > of events that all of a sudden either became important to > > > know about, or > > > you no longer want to hear about. Thus we should keep the RequestID. > > > > > > > > > Regards > > > > > > Flemming Andreasen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen <brosen(a)ENG.FORE.COM> on 04/09/99 08:18:46 AM > > > > > > 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: Flemming Andreasen/Bellcore) > > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > > > > > > > > > > As the protocol is currently defined, there is > > > thus thing we called a RequestID. You supply > > > a RequestID with the EventDescriptor, and it is > > > returned by the Notify. A RequestID is a 32 bit > > > integer. The syntax defines the requestID, and > > > uses it in the Notify, but does not show it in > > > the EventDescriptor. That should be fixed, but... > > > > > > As I noted, TerminationID + EventName is logically > > > equivalent to an MGC assigned RequestID if you > > > can only have one instance of an event on a > > > termination. Implementation seems to be simple > > > in either case at both ends. At the MG, storing > > > the requestID is easy, but not storing is easier. > > > At the MGC, the RequestID would be a separate table, > > > but it would have to have TerminationID and > > > EventName at least implicitly, and probably > > > explicitly in it. Searching a structure by > > > TerminationID and then EventName (or the other way > > > around) is also easy.Thinking about it overnight, if it > > > really is the same, then it would be best to > > > eliminate the RequestID artifice and use Termination > > > ID + EventName. > > > > > > At the time, I believed we thought that there were > > > circumstances where there was not uniqueness. Right > > > now, I can't see how that can occur. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Chip Sharp [mailto:chsharp@cisco.com] > > > > Sent: Thursday, April 08, 1999 5:46 PM > > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > > > > > > > Yes that was my understanding as well. The TerminationID > > > > would be used to > > > > associate the event to the termination. Thus the event > > report would > > > > contain the Termination ID and the event ID. > > > > > > > > Chip > > > > > > > > At 02:21 PM 4/8/99 -0700, Rex Coldren wrote: > > > > >Actually I believe this item was not correctly written. I > > > > believe the > > > > >discussion was about how you associate a reported event > > to a given > > > > >Termination. There was talk that notifications come back with a > > > > >RequestID, which must be somehow associated to a Termination. > > > > >Paul suggested using TerminationID directly. > > > > > > > > > >Christian Huitema wrote: > > > > > > > > > >> > 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 > > > > >> > > > > >> Sorry for missing the call, but let's comment on that > > > > specific point. We > > > > >> discussed the event reporting model at length during the > > > > IETF meetings and > > > > >> in the following week, and I don't beleive that there is > > > > any advantage in > > > > >> opening the debate again. > > > > >> > > > > >> Termination Id and event names just do not belong to the > > > > same space. > > > > >> Terminations are defined on a per MG basis; events are defined > > > > >> independently of the MG, and in many cases independently of the > > > > >> termination class. > > > > >> > > > > >> The current notifications identify both the termination on > > > > which the event > > > > >> was observed and the name of the event. There is a lot of > > > > experience to > > > > >> show that this is a very efficient decomposition, and I > > > > don't see any > > > > >> reason whatsoever for ditching the experience in favor of > > > > an unproven > > > > >> theoretical design. > > > > >> > > > > >> -- > > > > >> Christian Huitema > > > > >> ------------------------------ > > > > >> Please note my new address: huitema(a)research.telcordia.com > > > > >> http://www.telcordia.com/ > > > > > > > > > > > > > > -------------------------------------------------- > > > > Chip Sharp voice: +1 (919) 851-2085 > > > > Cisco Systems Consulting Eng. - Telco > > > > Reality - Love it or Leave it. > > > > -------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Paul Sijben Telno:+ 31 35 687 4774 Fax:+31 35 687 5954 Lucent Technologies Home telno: +31 33 4557522 Forward Looking Work e-mail: sijben(a)lucent.com Huizen, The Netherlands internal http://hzsgp68.nl.lucent.com/

2 1

Re: Event reporting (was audio call Thursday: Minutes)
by Flemming Andreasen 12 Apr '99

12 Apr '99

Well, such is the nature of glare - glare resolution is a different story and the MGC may implement whatever policy it wants. However, if it cannot determine the order of events, it becomes rather hard for it to achieve any kind of policy besides randomness. Having the ability to determine order would seem a solid design principle to me. Going back to lockstep again, it should be noted that without the RequestId, you will *always* have to issue a new request in response to it, since you don't know whether the Notify was generated before or after some request had been received - that's hardly a good solution since you are now forced to send more messages than needed and if signals are not idempotent, you may in fact not achieve what you desired. I still say there are lots of good reasons for a RequestID - is anybody opposed to including this ? Regards Flemming Brian Rosen <brosen(a)eng.fore.com> on 04/09/99 01:32:52 PM To: "'Flemming Andreasen'" <fandreas(a)telcordia.com> cc: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> (bcc: Flemming Andreasen/Bellcore) Subject: RE: Event reporting (was audio call Thursday: Minutes) Suppose the flash hook came .5 ms after the call waiting happened. Clearly the intention is to initiate a new call, but your email suggests it should connect to the waiting caller. It seems to me that whichever action the MGC takes on the event it can do the same thing with or without the RequestID. This is true because all the events we are discussing have long response times relative to MG/MGC communication. With timestamps (also a suggestion), it could do something approximating the right thing all the time with or without RequestIDs. Please note, I liked RequestIDs when they were suggested. I still like them, but I can't currently seem to defend them very well. Brian > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@telcordia.com] > Sent: Friday, April 09, 1999 12:58 PM > To: Mailing list for parties associated with ITU-T Study Group 16 > Cc: Flemming Andreasen; brosen(a)eng.fore.com > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > Consider the following example: > > 1. Party A is currently involved in a call with Party B. The > active request > for A is RA-1 > 2. Another call now arrives to A, who happens to subscribe to > call-waiting > as well as three-way calling. > 3a. The MGC decides that since A subscribes to call-waiting, > A should hear > call-waiting tones so the MGC sends a new request RA-2 to A > 3b. At the same time, party A could have decided to put B on > hold and place > another call. Party A would then generate a flash-hook which > results in a > Notify (N-x) message being sent to the MGC. > > Now, if RA-2 arrived at A prior to A generating the flash-hook, the > call-waiting tone would have been played prior to the > flash-hook, and the > correct glare resolution would probably be for the incoming call to be > connected. > > On the other hand, if RA-2 arrived at A after A generated the > flash-hook, > we should probably consider A to attempt to initiate a new > call, and the > correct glare resolution would probably be for the incoming > call to get > called-party-busy treatment, and for A to continue with the > call attempt. > (In this case, the call-waiting tone would actually be played > after the > flash-hook, so you may even have a need to specify that "the following > request is only to be applied if there is currently no outstanding > Notify"). Also note, that if the RA-2 message had been lost, > there would no > longer be a need for retransmitting it. > > The only way you can determine the order of events is by including the > request id (I would not favor a transaction-id based > approach), and I do > believe that order matters in some cases, so you might as > well include a > solution, especially when it's this simple. We can probably > come up with > more examples if needed. > > > Regards > > Flemming > > > > > > > > > > > > Brian Rosen <brosen(a)ENG.FORE.COM> on 04/09/99 11:48:08 AM > > 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: Flemming Andreasen/Bellcore) > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > You might be right, but I am confused. > > The simple case of lockstep works. The EventDescriptor is > set up with the event, it happens, you get notified, and you > send a modify to rearm it. If the event happens again before > the rearm, you ignore it. If it happens after, you get > another Notify. > > The only way I see a problem is when you have time order > of a Modify; you have a lockstep event "armed", you send down > a Modify with a new EventDescriptor, and the event either > happens before or after the Modify command is executed. > Perhaps you think it's important to know if the event > happened before or after the Modify, but I can't come up with > a scenario where it matters. If it does, then I agree, you > need a tag that is unique to the setting of the > EventDescriptor. > > I do note that you could (theoretically) report the > transactionID of the command that set the event. That would > make you sent TerminationID, Event Name and TransactionID on > the Notify. It would solve the problem. It might be better > to use RequestID rather than that. > > Brian > > > -----Original Message----- > > From: Flemming Andreasen [mailto:fandreas@telcordia.com] > > Sent: Friday, April 09, 1999 10:13 AM > > To: Mailing list for parties associated with ITU-T Study Group 16 > > Cc: brosen(a)eng.fore.com; Flemming Andreasen > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > > > > > There is actually a good reason for the RequestID. It > > basically enables you > > to determine whether a notification was issued before or after the > > reception of a given request for the notification. As an > > example where this > > is important, consider what we refer to as "lockstep mode". > > It essentially > > states that a given request can at most generate one Notify, > > which implies > > that after receiving a Notify you must send down a new > > request. Without a > > RequestID you cannot determine whether that request has already been > > received or not. This is not only protocol-wise important but > > semantically > > as well, as your new request may contain instructions to look > > for a new set > > of events that all of a sudden either became important to > > know about, or > > you no longer want to hear about. Thus we should keep the RequestID. > > > > > > Regards > > > > Flemming Andreasen > > > > > > > > > > > > > > > > > > > > > > Brian Rosen <brosen(a)ENG.FORE.COM> on 04/09/99 08:18:46 AM > > > > 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: Flemming Andreasen/Bellcore) > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > > > > > As the protocol is currently defined, there is > > thus thing we called a RequestID. You supply > > a RequestID with the EventDescriptor, and it is > > returned by the Notify. A RequestID is a 32 bit > > integer. The syntax defines the requestID, and > > uses it in the Notify, but does not show it in > > the EventDescriptor. That should be fixed, but... > > > > As I noted, TerminationID + EventName is logically > > equivalent to an MGC assigned RequestID if you > > can only have one instance of an event on a > > termination. Implementation seems to be simple > > in either case at both ends. At the MG, storing > > the requestID is easy, but not storing is easier. > > At the MGC, the RequestID would be a separate table, > > but it would have to have TerminationID and > > EventName at least implicitly, and probably > > explicitly in it. Searching a structure by > > TerminationID and then EventName (or the other way > > around) is also easy.Thinking about it overnight, if it > > really is the same, then it would be best to > > eliminate the RequestID artifice and use Termination > > ID + EventName. > > > > At the time, I believed we thought that there were > > circumstances where there was not uniqueness. Right > > now, I can't see how that can occur. > > > > Brian > > > > > -----Original Message----- > > > From: Chip Sharp [mailto:chsharp@cisco.com] > > > Sent: Thursday, April 08, 1999 5:46 PM > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > > > > Yes that was my understanding as well. The TerminationID > > > would be used to > > > associate the event to the termination. Thus the event > report would > > > contain the Termination ID and the event ID. > > > > > > Chip > > > > > > At 02:21 PM 4/8/99 -0700, Rex Coldren wrote: > > > >Actually I believe this item was not correctly written. I > > > believe the > > > >discussion was about how you associate a reported event > to a given > > > >Termination. There was talk that notifications come back with a > > > >RequestID, which must be somehow associated to a Termination. > > > >Paul suggested using TerminationID directly. > > > > > > > >Christian Huitema wrote: > > > > > > > >> > 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 > > > >> > > > >> Sorry for missing the call, but let's comment on that > > > specific point. We > > > >> discussed the event reporting model at length during the > > > IETF meetings and > > > >> in the following week, and I don't beleive that there is > > > any advantage in > > > >> opening the debate again. > > > >> > > > >> Termination Id and event names just do not belong to the > > > same space. > > > >> Terminations are defined on a per MG basis; events are defined > > > >> independently of the MG, and in many cases independently of the > > > >> termination class. > > > >> > > > >> The current notifications identify both the termination on > > > which the event > > > >> was observed and the name of the event. There is a lot of > > > experience to > > > >> show that this is a very efficient decomposition, and I > > > don't see any > > > >> reason whatsoever for ditching the experience in favor of > > > an unproven > > > >> theoretical design. > > > >> > > > >> -- > > > >> Christian Huitema > > > >> ------------------------------ > > > >> Please note my new address: huitema(a)research.telcordia.com > > > >> http://www.telcordia.com/ > > > > > > > > > > > -------------------------------------------------- > > > Chip Sharp voice: +1 (919) 851-2085 > > > Cisco Systems Consulting Eng. - Telco > > > Reality - Love it or Leave it. > > > -------------------------------------------------- > > > > > > > > > > > > > > > > > > > > >

2 1

H.320 to H.323 Gateways: Will They Decompose?
by Tom-PT Taylor 10 Apr '99

10 Apr '99

This is addressed to the experts of Study Group 16, but has impact on the priorities of work both for Megaco and for H.GCP. The question, which I raised obliquely in a previous exchange on co-location of H.245 signalling with the Media Gateway function, is whether any vendor will actually create a decomposed H.320-to-H.323 Gateway. If not, we can stop worrying about how to accommodate H.320 in the Media Gateway control protocol. Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 736 0961 (ESN 396-1490) FAX: same number by prior arrangement (manual answer).

2 1

Re: audio call Thursday: Minutes
by Bryan Hill 09 Apr '99

09 Apr '99

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(a)baynetworks.com'; 'itu-sg16(a)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

1 0

Re: H.320 to H.323 Gateways: Will They Decompose?
by Callaghan, Robert 09 Apr '99

09 Apr '99

May I extend the question to a decomposed H.324-to-H.323 Gateway. 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: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Friday, April 09, 1999 2:57 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.320 to H.323 Gateways: Will They Decompose? This is addressed to the experts of Study Group 16, but has impact on the priorities of work both for Megaco and for H.GCP. The question, which I raised obliquely in a previous exchange on co-location of H.245 signalling with the Media Gateway function, is whether any vendor will actually create a decomposed H.320-to-H.323 Gateway. If not, we can stop worrying about how to accommodate H.320 in the Media Gateway control protocol. Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 736 0961 (ESN 396-1490) FAX: same number by prior arrangement (manual answer).

1 0

Re: Event reporting (was audio call Thursday: Minutes)
by Brian Rosen 09 Apr '99

09 Apr '99

Suppose the flash hook came .5 ms after the call waiting happened. Clearly the intention is to initiate a new call, but your email suggests it should connect to the waiting caller. It seems to me that whichever action the MGC takes on the event it can do the same thing with or without the RequestID. This is true because all the events we are discussing have long response times relative to MG/MGC communication. With timestamps (also a suggestion), it could do something approximating the right thing all the time with or without RequestIDs. Please note, I liked RequestIDs when they were suggested. I still like them, but I can't currently seem to defend them very well. Brian > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@telcordia.com] > Sent: Friday, April 09, 1999 12:58 PM > To: Mailing list for parties associated with ITU-T Study Group 16 > Cc: Flemming Andreasen; brosen(a)eng.fore.com > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > Consider the following example: > > 1. Party A is currently involved in a call with Party B. The > active request > for A is RA-1 > 2. Another call now arrives to A, who happens to subscribe to > call-waiting > as well as three-way calling. > 3a. The MGC decides that since A subscribes to call-waiting, > A should hear > call-waiting tones so the MGC sends a new request RA-2 to A > 3b. At the same time, party A could have decided to put B on > hold and place > another call. Party A would then generate a flash-hook which > results in a > Notify (N-x) message being sent to the MGC. > > Now, if RA-2 arrived at A prior to A generating the flash-hook, the > call-waiting tone would have been played prior to the > flash-hook, and the > correct glare resolution would probably be for the incoming call to be > connected. > > On the other hand, if RA-2 arrived at A after A generated the > flash-hook, > we should probably consider A to attempt to initiate a new > call, and the > correct glare resolution would probably be for the incoming > call to get > called-party-busy treatment, and for A to continue with the > call attempt. > (In this case, the call-waiting tone would actually be played > after the > flash-hook, so you may even have a need to specify that "the following > request is only to be applied if there is currently no outstanding > Notify"). Also note, that if the RA-2 message had been lost, > there would no > longer be a need for retransmitting it. > > The only way you can determine the order of events is by including the > request id (I would not favor a transaction-id based > approach), and I do > believe that order matters in some cases, so you might as > well include a > solution, especially when it's this simple. We can probably > come up with > more examples if needed. > > > Regards > > Flemming > > > > > > > > > > > > Brian Rosen <brosen(a)ENG.FORE.COM> on 04/09/99 11:48:08 AM > > 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: Flemming Andreasen/Bellcore) > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > You might be right, but I am confused. > > The simple case of lockstep works. The EventDescriptor is > set up with the event, it happens, you get notified, and you > send a modify to rearm it. If the event happens again before > the rearm, you ignore it. If it happens after, you get > another Notify. > > The only way I see a problem is when you have time order > of a Modify; you have a lockstep event "armed", you send down > a Modify with a new EventDescriptor, and the event either > happens before or after the Modify command is executed. > Perhaps you think it's important to know if the event > happened before or after the Modify, but I can't come up with > a scenario where it matters. If it does, then I agree, you > need a tag that is unique to the setting of the > EventDescriptor. > > I do note that you could (theoretically) report the > transactionID of the command that set the event. That would > make you sent TerminationID, Event Name and TransactionID on > the Notify. It would solve the problem. It might be better > to use RequestID rather than that. > > Brian > > > -----Original Message----- > > From: Flemming Andreasen [mailto:fandreas@telcordia.com] > > Sent: Friday, April 09, 1999 10:13 AM > > To: Mailing list for parties associated with ITU-T Study Group 16 > > Cc: brosen(a)eng.fore.com; Flemming Andreasen > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > > > > > There is actually a good reason for the RequestID. It > > basically enables you > > to determine whether a notification was issued before or after the > > reception of a given request for the notification. As an > > example where this > > is important, consider what we refer to as "lockstep mode". > > It essentially > > states that a given request can at most generate one Notify, > > which implies > > that after receiving a Notify you must send down a new > > request. Without a > > RequestID you cannot determine whether that request has already been > > received or not. This is not only protocol-wise important but > > semantically > > as well, as your new request may contain instructions to look > > for a new set > > of events that all of a sudden either became important to > > know about, or > > you no longer want to hear about. Thus we should keep the RequestID. > > > > > > Regards > > > > Flemming Andreasen > > > > > > > > > > > > > > > > > > > > > > Brian Rosen <brosen(a)ENG.FORE.COM> on 04/09/99 08:18:46 AM > > > > 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: Flemming Andreasen/Bellcore) > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > > > > > As the protocol is currently defined, there is > > thus thing we called a RequestID. You supply > > a RequestID with the EventDescriptor, and it is > > returned by the Notify. A RequestID is a 32 bit > > integer. The syntax defines the requestID, and > > uses it in the Notify, but does not show it in > > the EventDescriptor. That should be fixed, but... > > > > As I noted, TerminationID + EventName is logically > > equivalent to an MGC assigned RequestID if you > > can only have one instance of an event on a > > termination. Implementation seems to be simple > > in either case at both ends. At the MG, storing > > the requestID is easy, but not storing is easier. > > At the MGC, the RequestID would be a separate table, > > but it would have to have TerminationID and > > EventName at least implicitly, and probably > > explicitly in it. Searching a structure by > > TerminationID and then EventName (or the other way > > around) is also easy.Thinking about it overnight, if it > > really is the same, then it would be best to > > eliminate the RequestID artifice and use Termination > > ID + EventName. > > > > At the time, I believed we thought that there were > > circumstances where there was not uniqueness. Right > > now, I can't see how that can occur. > > > > Brian > > > > > -----Original Message----- > > > From: Chip Sharp [mailto:chsharp@cisco.com] > > > Sent: Thursday, April 08, 1999 5:46 PM > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > > > > Yes that was my understanding as well. The TerminationID > > > would be used to > > > associate the event to the termination. Thus the event > report would > > > contain the Termination ID and the event ID. > > > > > > Chip > > > > > > At 02:21 PM 4/8/99 -0700, Rex Coldren wrote: > > > >Actually I believe this item was not correctly written. I > > > believe the > > > >discussion was about how you associate a reported event > to a given > > > >Termination. There was talk that notifications come back with a > > > >RequestID, which must be somehow associated to a Termination. > > > >Paul suggested using TerminationID directly. > > > > > > > >Christian Huitema wrote: > > > > > > > >> > 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 > > > >> > > > >> Sorry for missing the call, but let's comment on that > > > specific point. We > > > >> discussed the event reporting model at length during the > > > IETF meetings and > > > >> in the following week, and I don't beleive that there is > > > any advantage in > > > >> opening the debate again. > > > >> > > > >> Termination Id and event names just do not belong to the > > > same space. > > > >> Terminations are defined on a per MG basis; events are defined > > > >> independently of the MG, and in many cases independently of the > > > >> termination class. > > > >> > > > >> The current notifications identify both the termination on > > > which the event > > > >> was observed and the name of the event. There is a lot of > > > experience to > > > >> show that this is a very efficient decomposition, and I > > > don't see any > > > >> reason whatsoever for ditching the experience in favor of > > > an unproven > > > >> theoretical design. > > > >> > > > >> -- > > > >> Christian Huitema > > > >> ------------------------------ > > > >> Please note my new address: huitema(a)research.telcordia.com > > > >> http://www.telcordia.com/ > > > > > > > > > > > -------------------------------------------------- > > > Chip Sharp voice: +1 (919) 851-2085 > > > Cisco Systems Consulting Eng. - Telco > > > Reality - Love it or Leave it. > > > -------------------------------------------------- > > > > > > > > > > > > > > > > > > > > >

1 0

Re: Event reporting (was audio call Thursday: Minutes)
by Flemming Andreasen 09 Apr '99

09 Apr '99

Consider the following example: 1. Party A is currently involved in a call with Party B. The active request for A is RA-1 2. Another call now arrives to A, who happens to subscribe to call-waiting as well as three-way calling. 3a. The MGC decides that since A subscribes to call-waiting, A should hear call-waiting tones so the MGC sends a new request RA-2 to A 3b. At the same time, party A could have decided to put B on hold and place another call. Party A would then generate a flash-hook which results in a Notify (N-x) message being sent to the MGC. Now, if RA-2 arrived at A prior to A generating the flash-hook, the call-waiting tone would have been played prior to the flash-hook, and the correct glare resolution would probably be for the incoming call to be connected. On the other hand, if RA-2 arrived at A after A generated the flash-hook, we should probably consider A to attempt to initiate a new call, and the correct glare resolution would probably be for the incoming call to get called-party-busy treatment, and for A to continue with the call attempt. (In this case, the call-waiting tone would actually be played after the flash-hook, so you may even have a need to specify that "the following request is only to be applied if there is currently no outstanding Notify"). Also note, that if the RA-2 message had been lost, there would no longer be a need for retransmitting it. The only way you can determine the order of events is by including the request id (I would not favor a transaction-id based approach), and I do believe that order matters in some cases, so you might as well include a solution, especially when it's this simple. We can probably come up with more examples if needed. Regards Flemming Brian Rosen <brosen(a)ENG.FORE.COM> on 04/09/99 11:48:08 AM 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: Flemming Andreasen/Bellcore) Subject: Re: Event reporting (was audio call Thursday: Minutes) You might be right, but I am confused. The simple case of lockstep works. The EventDescriptor is set up with the event, it happens, you get notified, and you send a modify to rearm it. If the event happens again before the rearm, you ignore it. If it happens after, you get another Notify. The only way I see a problem is when you have time order of a Modify; you have a lockstep event "armed", you send down a Modify with a new EventDescriptor, and the event either happens before or after the Modify command is executed. Perhaps you think it's important to know if the event happened before or after the Modify, but I can't come up with a scenario where it matters. If it does, then I agree, you need a tag that is unique to the setting of the EventDescriptor. I do note that you could (theoretically) report the transactionID of the command that set the event. That would make you sent TerminationID, Event Name and TransactionID on the Notify. It would solve the problem. It might be better to use RequestID rather than that. Brian > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@telcordia.com] > Sent: Friday, April 09, 1999 10:13 AM > To: Mailing list for parties associated with ITU-T Study Group 16 > Cc: brosen(a)eng.fore.com; Flemming Andreasen > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > There is actually a good reason for the RequestID. It > basically enables you > to determine whether a notification was issued before or after the > reception of a given request for the notification. As an > example where this > is important, consider what we refer to as "lockstep mode". > It essentially > states that a given request can at most generate one Notify, > which implies > that after receiving a Notify you must send down a new > request. Without a > RequestID you cannot determine whether that request has already been > received or not. This is not only protocol-wise important but > semantically > as well, as your new request may contain instructions to look > for a new set > of events that all of a sudden either became important to > know about, or > you no longer want to hear about. Thus we should keep the RequestID. > > > Regards > > Flemming Andreasen > > > > > > > > > > > Brian Rosen <brosen(a)ENG.FORE.COM> on 04/09/99 08:18:46 AM > > 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: Flemming Andreasen/Bellcore) > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > As the protocol is currently defined, there is > thus thing we called a RequestID. You supply > a RequestID with the EventDescriptor, and it is > returned by the Notify. A RequestID is a 32 bit > integer. The syntax defines the requestID, and > uses it in the Notify, but does not show it in > the EventDescriptor. That should be fixed, but... > > As I noted, TerminationID + EventName is logically > equivalent to an MGC assigned RequestID if you > can only have one instance of an event on a > termination. Implementation seems to be simple > in either case at both ends. At the MG, storing > the requestID is easy, but not storing is easier. > At the MGC, the RequestID would be a separate table, > but it would have to have TerminationID and > EventName at least implicitly, and probably > explicitly in it. Searching a structure by > TerminationID and then EventName (or the other way > around) is also easy.Thinking about it overnight, if it > really is the same, then it would be best to > eliminate the RequestID artifice and use Termination > ID + EventName. > > At the time, I believed we thought that there were > circumstances where there was not uniqueness. Right > now, I can't see how that can occur. > > Brian > > > -----Original Message----- > > From: Chip Sharp [mailto:chsharp@cisco.com] > > Sent: Thursday, April 08, 1999 5:46 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > Yes that was my understanding as well. The TerminationID > > would be used to > > associate the event to the termination. Thus the event report would > > contain the Termination ID and the event ID. > > > > Chip > > > > At 02:21 PM 4/8/99 -0700, Rex Coldren wrote: > > >Actually I believe this item was not correctly written. I > > believe the > > >discussion was about how you associate a reported event to a given > > >Termination. There was talk that notifications come back with a > > >RequestID, which must be somehow associated to a Termination. > > >Paul suggested using TerminationID directly. > > > > > >Christian Huitema wrote: > > > > > >> > 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 > > >> > > >> Sorry for missing the call, but let's comment on that > > specific point. We > > >> discussed the event reporting model at length during the > > IETF meetings and > > >> in the following week, and I don't beleive that there is > > any advantage in > > >> opening the debate again. > > >> > > >> Termination Id and event names just do not belong to the > > same space. > > >> Terminations are defined on a per MG basis; events are defined > > >> independently of the MG, and in many cases independently of the > > >> termination class. > > >> > > >> The current notifications identify both the termination on > > which the event > > >> was observed and the name of the event. There is a lot of > > experience to > > >> show that this is a very efficient decomposition, and I > > don't see any > > >> reason whatsoever for ditching the experience in favor of > > an unproven > > >> theoretical design. > > >> > > >> -- > > >> Christian Huitema > > >> ------------------------------ > > >> Please note my new address: huitema(a)research.telcordia.com > > >> http://www.telcordia.com/ > > > > > > > > -------------------------------------------------- > > Chip Sharp voice: +1 (919) 851-2085 > > Cisco Systems Consulting Eng. - Telco > > Reality - Love it or Leave it. > > -------------------------------------------------- > > > > > > > >

1 0

H.226 Usage
by Chip Sharp 09 Apr '99

09 Apr '99

Could someone email me privately and help me understand the application for H.226? H.221 already provides channel aggregation for H.320. It's unclear from the text itself what it is to be used for. I assume that all the explanatory text was removed from the draft before it got to the white paper stage. Thanks, Chip -------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Consulting Eng. - Telco Reality - Love it or Leave it. --------------------------------------------------

1 0

Re: Event reporting (was audio call Thursday: Minutes)
by Brian Rosen 09 Apr '99

09 Apr '99

You might be right, but I am confused. The simple case of lockstep works. The EventDescriptor is set up with the event, it happens, you get notified, and you send a modify to rearm it. If the event happens again before the rearm, you ignore it. If it happens after, you get another Notify. The only way I see a problem is when you have time order of a Modify; you have a lockstep event "armed", you send down a Modify with a new EventDescriptor, and the event either happens before or after the Modify command is executed. Perhaps you think it's important to know if the event happened before or after the Modify, but I can't come up with a scenario where it matters. If it does, then I agree, you need a tag that is unique to the setting of the EventDescriptor. I do note that you could (theoretically) report the transactionID of the command that set the event. That would make you sent TerminationID, Event Name and TransactionID on the Notify. It would solve the problem. It might be better to use RequestID rather than that. Brian > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@telcordia.com] > Sent: Friday, April 09, 1999 10:13 AM > To: Mailing list for parties associated with ITU-T Study Group 16 > Cc: brosen(a)eng.fore.com; Flemming Andreasen > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > There is actually a good reason for the RequestID. It > basically enables you > to determine whether a notification was issued before or after the > reception of a given request for the notification. As an > example where this > is important, consider what we refer to as "lockstep mode". > It essentially > states that a given request can at most generate one Notify, > which implies > that after receiving a Notify you must send down a new > request. Without a > RequestID you cannot determine whether that request has already been > received or not. This is not only protocol-wise important but > semantically > as well, as your new request may contain instructions to look > for a new set > of events that all of a sudden either became important to > know about, or > you no longer want to hear about. Thus we should keep the RequestID. > > > Regards > > Flemming Andreasen > > > > > > > > > > > Brian Rosen <brosen(a)ENG.FORE.COM> on 04/09/99 08:18:46 AM > > 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: Flemming Andreasen/Bellcore) > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > As the protocol is currently defined, there is > thus thing we called a RequestID. You supply > a RequestID with the EventDescriptor, and it is > returned by the Notify. A RequestID is a 32 bit > integer. The syntax defines the requestID, and > uses it in the Notify, but does not show it in > the EventDescriptor. That should be fixed, but... > > As I noted, TerminationID + EventName is logically > equivalent to an MGC assigned RequestID if you > can only have one instance of an event on a > termination. Implementation seems to be simple > in either case at both ends. At the MG, storing > the requestID is easy, but not storing is easier. > At the MGC, the RequestID would be a separate table, > but it would have to have TerminationID and > EventName at least implicitly, and probably > explicitly in it. Searching a structure by > TerminationID and then EventName (or the other way > around) is also easy.Thinking about it overnight, if it > really is the same, then it would be best to > eliminate the RequestID artifice and use Termination > ID + EventName. > > At the time, I believed we thought that there were > circumstances where there was not uniqueness. Right > now, I can't see how that can occur. > > Brian > > > -----Original Message----- > > From: Chip Sharp [mailto:chsharp@cisco.com] > > Sent: Thursday, April 08, 1999 5:46 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > > > > Yes that was my understanding as well. The TerminationID > > would be used to > > associate the event to the termination. Thus the event report would > > contain the Termination ID and the event ID. > > > > Chip > > > > At 02:21 PM 4/8/99 -0700, Rex Coldren wrote: > > >Actually I believe this item was not correctly written. I > > believe the > > >discussion was about how you associate a reported event to a given > > >Termination. There was talk that notifications come back with a > > >RequestID, which must be somehow associated to a Termination. > > >Paul suggested using TerminationID directly. > > > > > >Christian Huitema wrote: > > > > > >> > 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 > > >> > > >> Sorry for missing the call, but let's comment on that > > specific point. We > > >> discussed the event reporting model at length during the > > IETF meetings and > > >> in the following week, and I don't beleive that there is > > any advantage in > > >> opening the debate again. > > >> > > >> Termination Id and event names just do not belong to the > > same space. > > >> Terminations are defined on a per MG basis; events are defined > > >> independently of the MG, and in many cases independently of the > > >> termination class. > > >> > > >> The current notifications identify both the termination on > > which the event > > >> was observed and the name of the event. There is a lot of > > experience to > > >> show that this is a very efficient decomposition, and I > > don't see any > > >> reason whatsoever for ditching the experience in favor of > > an unproven > > >> theoretical design. > > >> > > >> -- > > >> Christian Huitema > > >> ------------------------------ > > >> Please note my new address: huitema(a)research.telcordia.com > > >> http://www.telcordia.com/ > > > > > > > > -------------------------------------------------- > > Chip Sharp voice: +1 (919) 851-2085 > > Cisco Systems Consulting Eng. - Telco > > Reality - Love it or Leave it. > > -------------------------------------------------- > > > > > > > >

1 0

Re: Event reporting (was audio call Thursday: Minutes)
by Flemming Andreasen 09 Apr '99

09 Apr '99

There is actually a good reason for the RequestID. It basically enables you to determine whether a notification was issued before or after the reception of a given request for the notification. As an example where this is important, consider what we refer to as "lockstep mode". It essentially states that a given request can at most generate one Notify, which implies that after receiving a Notify you must send down a new request. Without a RequestID you cannot determine whether that request has already been received or not. This is not only protocol-wise important but semantically as well, as your new request may contain instructions to look for a new set of events that all of a sudden either became important to know about, or you no longer want to hear about. Thus we should keep the RequestID. Regards Flemming Andreasen Brian Rosen <brosen(a)ENG.FORE.COM> on 04/09/99 08:18:46 AM 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: Flemming Andreasen/Bellcore) Subject: Re: Event reporting (was audio call Thursday: Minutes) As the protocol is currently defined, there is thus thing we called a RequestID. You supply a RequestID with the EventDescriptor, and it is returned by the Notify. A RequestID is a 32 bit integer. The syntax defines the requestID, and uses it in the Notify, but does not show it in the EventDescriptor. That should be fixed, but... As I noted, TerminationID + EventName is logically equivalent to an MGC assigned RequestID if you can only have one instance of an event on a termination. Implementation seems to be simple in either case at both ends. At the MG, storing the requestID is easy, but not storing is easier. At the MGC, the RequestID would be a separate table, but it would have to have TerminationID and EventName at least implicitly, and probably explicitly in it. Searching a structure by TerminationID and then EventName (or the other way around) is also easy.Thinking about it overnight, if it really is the same, then it would be best to eliminate the RequestID artifice and use Termination ID + EventName. At the time, I believed we thought that there were circumstances where there was not uniqueness. Right now, I can't see how that can occur. Brian > -----Original Message----- > From: Chip Sharp [mailto:chsharp@cisco.com] > Sent: Thursday, April 08, 1999 5:46 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > Yes that was my understanding as well. The TerminationID > would be used to > associate the event to the termination. Thus the event report would > contain the Termination ID and the event ID. > > Chip > > At 02:21 PM 4/8/99 -0700, Rex Coldren wrote: > >Actually I believe this item was not correctly written. I > believe the > >discussion was about how you associate a reported event to a given > >Termination. There was talk that notifications come back with a > >RequestID, which must be somehow associated to a Termination. > >Paul suggested using TerminationID directly. > > > >Christian Huitema wrote: > > > >> > 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 > >> > >> Sorry for missing the call, but let's comment on that > specific point. We > >> discussed the event reporting model at length during the > IETF meetings and > >> in the following week, and I don't beleive that there is > any advantage in > >> opening the debate again. > >> > >> Termination Id and event names just do not belong to the > same space. > >> Terminations are defined on a per MG basis; events are defined > >> independently of the MG, and in many cases independently of the > >> termination class. > >> > >> The current notifications identify both the termination on > which the event > >> was observed and the name of the event. There is a lot of > experience to > >> show that this is a very efficient decomposition, and I > don't see any > >> reason whatsoever for ditching the experience in favor of > an unproven > >> theoretical design. > >> > >> -- > >> Christian Huitema > >> ------------------------------ > >> Please note my new address: huitema(a)research.telcordia.com > >> http://www.telcordia.com/ > > > > > -------------------------------------------------- > Chip Sharp voice: +1 (919) 851-2085 > Cisco Systems Consulting Eng. - Telco > Reality - Love it or Leave it. > -------------------------------------------------- >

2 1

H.320 to H.323 Gateways: Will They Decompose?
by Taylor, Tom-PT [CAR:5V00-I:EXCH] 09 Apr '99

09 Apr '99

This is addressed to the experts of Study Group 16, but has impact on the priorities of work both for Megaco and for H.GCP. The question, which I raised obliquely in a previous exchange on co-location of H.245 signalling with the Media Gateway function, is whether any vendor will actually create a decomposed H.320-to-H.323 Gateway. If not, we can stop worrying about how to accommodate H.320 in the Media Gateway control protocol. Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 736 0961 (ESN 396-1490) FAX: same number by prior arrangement (manual answer).

1 0

Re: Event reporting (was audio call Thursday: Minutes)
by Brian Rosen 09 Apr '99

09 Apr '99

As the protocol is currently defined, there is thus thing we called a RequestID. You supply a RequestID with the EventDescriptor, and it is returned by the Notify. A RequestID is a 32 bit integer. The syntax defines the requestID, and uses it in the Notify, but does not show it in the EventDescriptor. That should be fixed, but... As I noted, TerminationID + EventName is logically equivalent to an MGC assigned RequestID if you can only have one instance of an event on a termination. Implementation seems to be simple in either case at both ends. At the MG, storing the requestID is easy, but not storing is easier. At the MGC, the RequestID would be a separate table, but it would have to have TerminationID and EventName at least implicitly, and probably explicitly in it. Searching a structure by TerminationID and then EventName (or the other way around) is also easy.Thinking about it overnight, if it really is the same, then it would be best to eliminate the RequestID artifice and use Termination ID + EventName. At the time, I believed we thought that there were circumstances where there was not uniqueness. Right now, I can't see how that can occur. Brian > -----Original Message----- > From: Chip Sharp [mailto:chsharp@cisco.com] > Sent: Thursday, April 08, 1999 5:46 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Event reporting (was audio call Thursday: Minutes) > > > Yes that was my understanding as well. The TerminationID > would be used to > associate the event to the termination. Thus the event report would > contain the Termination ID and the event ID. > > Chip > > At 02:21 PM 4/8/99 -0700, Rex Coldren wrote: > >Actually I believe this item was not correctly written. I > believe the > >discussion was about how you associate a reported event to a given > >Termination. There was talk that notifications come back with a > >RequestID, which must be somehow associated to a Termination. > >Paul suggested using TerminationID directly. > > > >Christian Huitema wrote: > > > >> > 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 > >> > >> Sorry for missing the call, but let's comment on that > specific point. We > >> discussed the event reporting model at length during the > IETF meetings and > >> in the following week, and I don't beleive that there is > any advantage in > >> opening the debate again. > >> > >> Termination Id and event names just do not belong to the > same space. > >> Terminations are defined on a per MG basis; events are defined > >> independently of the MG, and in many cases independently of the > >> termination class. > >> > >> The current notifications identify both the termination on > which the event > >> was observed and the name of the event. There is a lot of > experience to > >> show that this is a very efficient decomposition, and I > don't see any > >> reason whatsoever for ditching the experience in favor of > an unproven > >> theoretical design. > >> > >> -- > >> Christian Huitema > >> ------------------------------ > >> Please note my new address: huitema(a)research.telcordia.com > >> http://www.telcordia.com/ > > > > > -------------------------------------------------- > Chip Sharp voice: +1 (919) 851-2085 > Cisco Systems Consulting Eng. - Telco > Reality - Love it or Leave it. > -------------------------------------------------- >

1 0

Re: Transport issue (was: audio call Thursday: Minutes)
by Krishna Kurpati 09 Apr '99

09 Apr '99

I think both TCP and UDP should be provided as options. Particularly with Trunking Gateways TCP can be used as transport mechanism. Since there would be less number of these gateways (in most cases two or four per Call Agent) there will be less number of connections to manage. TCP provides better communication with Trunking gateways in that there is no need to maintain timers and retransmission acks for large number of transactions between Call Agent and Trunking gateway. Three-way hand shaking and retransmission will be costly in this case. For residential gateways they may be over 10000 per Call Agent. Managing 10000 connections is not a good idea. Also, only 5-10% of the time, residential gateway will communicate with call agent. For this maintaining a connection is big overhead. In this case, UDP is preferred. IMHO, there is a need to segragate transport profiles for residential gateways and trunking gateways. Regards Krishna Kurapati -----Original Message----- From: Christian Huitema [SMTP:huitema@research.telcordia.com] Sent: Thursday, April 08, 1999 3:40 PM To: Greene, Nancy-M [CAR:5N10:EXCH]; 'megaco(a)baynetworks.com'; 'itu-sg16(a)mailbag.intel.com' Subject: Transport issue (was: audio call Thursday: Minutes) > 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. Using TCP would be a serious problem in large configurations. Our experience is that UDP+timers has a wider applicability and is not in practice harder to implement than TCP -- you have to manage timers, but then you don't have to manage connections. -- Christian Huitema ------------------------------ Please note my new address: huitema(a)research.telcordia.com http://www.telcordia.com/

1 0

Event reporting (was audio call Thursday: Minutes)
by Christian Huitema 08 Apr '99

08 Apr '99

> 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 Sorry for missing the call, but let's comment on that specific point. We discussed the event reporting model at length during the IETF meetings and in the following week, and I don't beleive that there is any advantage in opening the debate again. Termination Id and event names just do not belong to the same space. Terminations are defined on a per MG basis; events are defined independently of the MG, and in many cases independently of the termination class. The current notifications identify both the termination on which the event was observed and the name of the event. There is a lot of experience to show that this is a very efficient decomposition, and I don't see any reason whatsoever for ditching the experience in favor of an unproven theoretical design. -- Christian Huitema ------------------------------ Please note my new address: huitema(a)research.telcordia.com http://www.telcordia.com/

3 2

Transport issue (was: audio call Thursday: Minutes)
by Christian Huitema 08 Apr '99

08 Apr '99

> 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. Using TCP would be a serious problem in large configurations. Our experience is that UDP+timers has a wider applicability and is not in practice harder to implement than TCP -- you have to manage timers, but then you don't have to manage connections. -- Christian Huitema ------------------------------ Please note my new address: huitema(a)research.telcordia.com http://www.telcordia.com/

1 0

audio call Thursday: Minutes
by Nancy-M Greene 08 Apr '99

08 Apr '99

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

1 0

PER ASN Encode of Open type elements
by Manoj Paul 07 Apr '99

07 Apr '99

We would like to seek opinion about the PER ASN encoding of open type elements (such as extension additions in sequence/choice etc.). Such an encoding requires unconstrained length "len" to be appended before the actual field-list of open type element, where "len" is the number of octets in open type element field list encoding. There seem to be the following ways to achieve this: a) Keep encoding the open type element and when it's encoding is finished, count the number of octets in it's encoded value and add that before the encoded value as unconstrained length. b) Just parse through open type element encode rules and find the number of octets it will need. Encode this number as unconstrained length and then do the acutal encode of the open type element value. Implementing (a), on most systems might be expensive, as it will need writing "len" value somewhere in the middle of the message. (b) is also not desirable from performance point of view as it needs double parse. Encoding "len" value less than 16K (which it mostly will) as uncostrained length requires two bytes. But X-691 also says that this length should be encoded in one byte if it is less than 127. Is it conforming to X-691, if length value less than 127 is also encoded in two bytes? That way, we know that whatever be the overall number of octets in encoded open type element field list, we will encode "len" in two octets and keep a place holder for these twp bytes before actually encoding the open type value. These "len" octets can then be written to contain unconstrained length of open type value. This procedure will save the inefficiencies mentioned in (a) and (b) above. But then the catch being if length less than 127 can be encoded in two octets. best regards Manoj Paul. +------------------------------+--------------------------------------+ |Manoj Paul | Trillium Digital Systems, Inc | |Member of Technical Staff | 12100 Wilshire Blvd #1800 | |E-mail:mpaul@trillium.com | Los Angeles, California 90025 | |Tel: +1(310)-442-9222 | U.S.A | +------------------------------+--------------------------------------+

2 1

Re: ASN.1 vs Text
by Paul Long 07 Apr '99

07 Apr '99

The experiment should implement the entire protocol and include a large set of messages. The syntax should then be extended in various ways. Text encoding is seductive. At first, text looks easier than ASN.1, but as more complex structures are needed and the syntax grows, it becomes cumbersome and error-prone. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Tom-PT Taylor [SMTP:taylor@NORTELNETWORKS.COM] Sent: Wednesday, March 31, 1999 9:17 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: ASN.1 vs Text Since the other responses seem to have gone off into a discussion of firewalls, let me respond to this more directly by recalling a bit of past discussion. 1) On the Megaco list, we finally agreed that the text vs. binary question is something to be resolved by experiment. 2) In Turin (I think), the general opinion was that the protocol would have to be binary to achieve the required performance. Interestingly enough, however, no one that I recall felt that it should be PER ASN.1 (or even, I think, BER ASN.1). Good reasons were given at the time. It would be good if someone can remember them, but I think it has something to do with processing performance and less risk of fragmentation than call signalling. 3) We have had an occasionally recurring suggestion on the Megaco list that the Media Gateway control protocol should conform to the format of other messaging out of the MGC, for the reason you give (i.e. to minimize transcoding). Interestingly, the person advocating this was talking about billing data, not signalling. The counter-argument on the list is that the Media Gateway control protocol must work with different signalling protocols (for example in H.GCP's case, with any of the H-series systems), so there is no point in optimizing it for just one. The real sticking point of debate is going to be whether the media description structures will be those defined for H.245 OLC etc., or SDP. Text vs. binary is a closely related but broader debate. I'd suggest we start thinking about experimental design. > -----Original Message----- > From: Ami Amir [SMTP:amir@RADVISION.RAD.CO.IL] > Sent: Wednesday, March 31, 1999 4:15 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.320 gateways a MEGACO / ITU > > Hi > > During the last MEGACO conference call - Tom Taylor asked what could > hinder > ITU acceptance of the MEGACO work. It is obviously to everybody's interest > that IETF and ITU standards merge. As an example - it would be great if > the > MEGACO work could become an ITU SG 16 contribution. > > An obvious item is efficient multimedia support (as reflected also in > John's > mail). > > However, I think that one of the even more major difficulties facing us > will > be the encoding scheme (ASN.1 vs Text). > > There are many who feel that ASN.1 is too heavy and complex for simple > devices, and should be avoided. This was one of the major reasons for the > emergence of SIP. > > On the other hand, experience in the ITU H.323 work has shown that since > ASN.1 is the encoding scheme on the PSTN side, the use of ASN cleared the > way for PSTN to IP interoperability. This feature will be extremely > important in hybrid networks that need to provide Intelligent Network (IN) > services (e.g. "800"), while retaining the investment in existing IN, > billing and directory services (411). > > Another problem is that if ASN.1 is not chosen, every device that will > have > to connect between a MEGACO component and H.323 will need to dis-assemble > and re-assemble (transcode) messages, and hence network performance will > suffer, and those devices will be more complex. A prime example - MGC to > GK > communications. > > I am not promoting a specific approach. I just think that this complex > issue > needs to be addressed if we want to be able to be able accept a universal > protocol. > > Do you think this is really a problem? > If so - any ideas on how to bridge the gap? > > Ami > > -----Original Message----- > From: John Segers [SMTP:jsegers@lucent.com] > Sent: Tuesday, March 30, 1999 6:27 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: H.320 gateways > > People, > > In yesterday's conference call, the subject of H.320 GWs was > raised > briefly. In my opinion, the connection model and protocol should > be > able > to deal with H.320. I would like to continue discussion on it on > the > mailing list. > > H.320 allows a user to have a session with both audio and video on > a > single 64 kbit/s channel such as an ISDN B-channel. The same > channel > carries some signalling information (frame alignment, bitrate > allocation). To a MG supporting H.320, this means that on a > single > endpoint, three streams can come in, carrying different types of > media. > The current connection model of megaco/H.gcp does not cater to > this. > I > see two possible solutions: > > The first is to allow multiple media in one context and to > describe > for > terminations the logical streams they carry. In a picture: > > +----------+ > | | > | +--------- signalling (FAS, BAS) > | | > B-channel ==========+ +--------- audio (16 kbit/s) > | | > | +--------- video (46.4 kbit/s) > | | > +----------+ > > The second solution is to have separate terminations for the > different > streams. They would all "connect to" the same physical endpoint. > In > order to properly identify the terminations, it is necessary to > have > logical names for them. The physical endpoint they connect may > have > the > hierarchical name proposed in the megaco document. > > Another example of a H.320 session is the case of two B-channels > being > used for an audiovisual call. The following frame structure is > then > possible. > > +--------------------------++-----------------------+ > | Channel 1 || Channel 2 | > +-----+--+--+--+--+--+--+--++--+--+--+--+--+--+--+--+ > |Bit 1|B2|B3|B4|B5|B6|B7|B8||B1|B2|B3|B4|B5|B6|B7|B8| > +-----+--+--+--+--+--+--+--++--+--+--+--+--+--+--+--+ > 1 | a1 |a2|a3|a4|a5|a6|v1|F ||v2|v3|v4|v5|v6|v7|v8|F | > 2 | a7 |a8|a9|a |a |a |v9|F ||v |v |v |v |v |v |v |F | > 3 | a |a |a |a |a |a |v |F ||v |v |v |v |v |v |v |F | > 4 | a | | | | |a |v |F ||v | |v |F | > 5 | a | | | | |a |v |F ||v | |v |F | > 6 | a | | | | |a |v |F ||v | |v |F | > 7 | a | | | | |a |v |F ||v | |v |F | > 8 | a | | | | |a |v |F ||v | |v |F | > +---------------------------------------------------+ > 9 | a | | | | |a |v |B ||v | |v |B | > 10 | a | | | | |a |v |B ||v | |v |B | > 11 | a | | | | |a |v |B ||v | |v |B | > 12 | a | | | | |a |v |B ||v | |v |B | > 13 | a | | | | |a |v |B ||v | |v |B | > 14 | a | | | | |a |v |B ||v | |v |B | > 15 | a | | | | |a |v |B ||v | |v |B | > 16 | a | | | | |a |v |B ||v | |v |B | > +---------------------------------------------------+ > 17 | a | | | | |a |v |v ||v | |v |v | > . > . > . > 80 | a | | | | |a |v |v ||v | |v |v | > +---------------------------------------------------+ > > (a=audio, v=video, F=FAS, B=BAS). > > We see that the video stream is split up over two channels. In > order to > cater to this, it seems we have to allow terminations to receive > media > from and send it to multiple physical endpoints. The two > approaches > outlined above can both be extended to allow this. Both extensions > will > lead to the introduction of logical names for terminations. In > the > first approach there will be one termination "containing" two > B-channels > on one side and three logical streams on the other. In the second > approach there will be three terminations, the one for the video > stream > referencing both B-channels, the ones for signalling and audio > referencing only channel 1. > > The second approach allows us to keep separate contexts for > different > media types. It is then easy to delete, for instance, the video > part of > a session (session used loosely to desribe the contexts for the > audio > and video). > > The first approach groups the streams coming from/going to one > user, > making it possible to remove a user from a context more easily. > > > Personally, I can't decide which approach I would prefer. How do > others > feel about these ideas? > > Regards, > > John Segers > -- > John Segers email: > jsegers(a)lucent.com > Lucent Technologies Room HE > 344 > Dept. Forward Looking Work phone: +31 35 687 > 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 > 5954

2 1

joining the megaco list
by Nancy-M Greene 07 Apr '99

07 Apr '99

Some of you have been asking how to join the IETF Megaco working group mailing list. Here is how: Send a message to majordomo(a)baynetworks.com with subscribe megaco end in the message body. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

Re: Firewalls [was: H.320 gateways a MEGACO / ITU]
by Melinda Shore 07 Apr '99

07 Apr '99

There's an awful lot of overlap between HFCI and SOCKS. Additionally, HFCI is still rather incomplete yet has some enormously useful stuff in it, so I'm hopeful that w'll be able to resolve these two over the next 3-6 months within the IETF or elsewhere. Melinda At 12:09 PM 4/6/99 +0100, Iain Barker wrote: >One solution would be not to expect the firewall to 'find' >which ports to open, but instead for the gateway to inform >the firewall of the nature of the underlying connection. > >FYI, SIEMENS have a submission to TIPHON which disusses how a >media gateway [H.323 in their example] can instruct the firewall >which IP ports to allow through. Melinda Shore Member of the Scientific Staff Nokia IP Telephony 127 West State Street Ithaca, New York 14850 +1 607 273 0724 x81 (office) +1 607 275 3610 (fax) +1 607 280 0010 (mobile) shore(a)ithaca-viennasys.com

2 1

audio call Thursday
by Bryan Hill 06 Apr '99

06 Apr '99

We decided at the last audio call March 29th/99 (minutes went out the same day), to hold the next call Thursday April 8th/99. The goal of the call is to move towards agreement for content of H.GCP, based on the draft Megaco protocol (draft-ietf-megaco-protocol-00.txt). As well, the call is a place where issues with the protocol can be discussed, and questions answered. As before, no "decisions" can be made on the call. Minutes will be posted to both itu-sg16(a)mailbag.intel.com <mailto:itu-sg16@mailbag.intel.com> and megaco(a)baynetworks.com <mailto:megaco@baynetworks.com> . Content discussion of the Megaco protocol, by convention, is taking place on the megaco(a)baynetworks.com <mailto:megaco@baynetworks.com> list. Here are the call details: Date: April 8th, 1999 Time: 10amEDT - 12pmEDT (we switched to EDT on Apr 4th) Phone #: 1-613-763-6338 PassCode: 131313# (same as last time) ***Problems getting on? please call 1-613-765-CONF and ask for the conference chaired by Nancy Greene. ***Please share ports with colleagues if possible. 60 ports have been booked. ***Because of the large # of participants, no tones will announce people entering or leaving the conference. ***Please mute your phone when you are not speaking (use either your mute button or press 63 to mute and 66 to unmute) Nancy Greene Bryan Hill ngreene(a)nortelnetworks.com <mailto:ngreene@nortelnetworks.com> bhill(a)videoserver.com <mailto:bhill@videoserver.com>

1 0

Re: Issues Around Support of Multimedia
by Christian Huitema 06 Apr '99

06 Apr '99

Tom, I agree with your analysis of requirements. We need to support multuimedia conference, yet we should not loose sight that H.320 is only a very small fraction of the initial market, and that we should not unduly increase the complexity of an audio only system. I also agree that we have to support multicast, and that we have to provide for fancy control of (at least some) conferences. The architecture we had in mind, as Brian explained, is to have one context per media. This brings in the notion of a "context type" -- an audio bridge, a video bridge, a T.120 bridge all behave somewhat differently. In fact, the particular realm of video bridging is prone to divisions such as "single image", "mosaic", "incrustations", which could be defined as context level parameters. In fact, a common practice on the MBONE is to carry several video streams on the same RTP association, using the SSRC as the stream identifier, and letting individual recipients select which video is displayed and which one is iconized. Short of that, conference control does not appear to be a real problem with the current spec. The mode parameter allows the MGC to specify the terminations that "contribute" to the mix (allowed to send) and the ones that only receive information. In a video bridge, the contributing terminations are sent in the mosaic, or multiplexed as RTP streams. In a T.120 bridge, the "master" termination is authorized to contribute, the other one remain passive. Synchronization of multiple context can be performed by the MGC: event reporting allows it to detect the last speaker, or video activity, or T.120 activity, and to issue MODIFY command that manage the conference accordingly. If the event/command chain is deemed to slow, then we will have to resort to a local script, a surrogate for the MGC. But there is more. Support for H.320 requires, in particular, the support for H.221 multiplexing of several streams onto a single carrier. That support is somewhat similar to the support of several DS0 inside a single DS1, or several B-Channels, albeit there are some obvious differences -- multiplexing parameters vary on a call per call basis, or even within a call. We have to express the notion that a specific termination, for the duration of a call, is "exploded" into a set of ephemeral terminations, each of which is then connected to a media specific context. This requires an additional mechanism, something like a 'demultiplexing context'. Demultiplexing has a symmetric, inverse multiplexing. This happens when an H.320 conference spans several B channels. It can also happen for data calls. In order to at least obtain the "warm and fuzzy feeling" that Fernando mentions, we have at a minimum to sketch out our solution to inverse multiplexing and demultiplexing, and maybe to propose one way to handle H.320. -- Christian Huitema ------------------------------ Please note my new address: huitema(a)research.telcordia.com http://www.telcordia.com/

1 0

FW: AW: Call hold and transfer in H.323 AnnexF. Too limited??
by Chris Purvis 06 Apr '99

06 Apr '99

All, I find it hard to believe that we can't do better (from the user's point of view) than the old black-phone view of the world whereby people have to type in various combinations of *s and digits to mean various different things to the local exchange. Most endpoints, after all, have pretty UIs. Now at the messaging level it may well make sense to have things APPEAR as if that (ie the typing of arcane sequences of digits) is what is happening - and it's possible that all we need to do to make that work in an interoperable way is to define what sequences of characters in the destination address in a setup message mean what sort of service. Do we start from a point such as "Setup with a single destination address which is e164 starting with '*' means arcane supplementary service", or define another alias type for "arcane supplementary service" or what? My aim is simply that an endpoint vendor should be ABLE to write things that do not require the user to understand bizarre control sequences, and will be able to access supplementary services wherever, and by whatever vendor, they are provided. Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis(a)madge.com > -----Original Message----- > From: Espen Skjæran [mailto:Espen.Skjaeran@ERICSSON.COM] > Sent: 26 March 1999 6:42 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: AW: Call hold and transfer in H.323 AnnexF. Too limited?? > > > Hei, > > I do not think it is a bad thing if ISPs choose to control service > profiles/configuration outside of H.450. There are a lot > more flexible ways to transport data. Proven technologies > exist today which are > very flexible and extendible (HTTP, WAP, IVRs, etc). User > oriented services > might also include non-H.323 equipment (mobile, email, even a > SIP terminal!), so > confining it to H.450 and H.323 would limit the possibillity > for "fancy" > services significantly, thereby also limiting the > distribution of H.323. > > If a Call Forward service is put in the network, it turns > more into a user > oriented than an endpoint oriented service, and the > possibilities for extensions are huge. As soon as the "Call > Forward Unreachable" > is standardized, I might come up with a proposal for call > forward based on > week/time, and this will hardly ever stop. We need a flexible > mechanism for > controlling these services, not new detailed service specifications. > > As the mechanisms for a call forward done in the network does > not require the > same level of interactions as a terminal > oriented (or in-call) service, we do not need to follow the > same approach as > H.450, where services are specified in detail. > The H.450 approach makes the creation (and extension) of a > service a very > lenghty process, and is actually a great > obstacle to creativity and development of new user oriented > services. (Though > for in-call services I don't see any way around it...) > > Espen > > > "Derks, Frank" wrote: > > > Paul, > > > > you got my points exactly right. The reason that I weakened > by arguments by > > hinting at the ease of upgrade in an IP environment was to > avoid people > > coming back with this line of argument. Although using > "DTMF digits" as the > > means to access services may not be the most elegant one, > it is probably the > > simplest and it maps well onto a simple "blackphone" type > of terminal. If we > > do not provide for something fairly simple (both for the > users and the > > service providers) then the chances are that service > providers will come up > > with "(IP) Telephony unrelated" means to access services. > E.g. they could > > provide Web pages that allow customers to specify their > service behaviour. > > > > Frank > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paul.jones@TIES.ITU.INT] > > Sent: 22 March 1999 19:11 > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: AW: Call hold and transfer in H.323 AnnexF. > Too limited?? > > > > Frank, > > > > I do agree that two mechanisms for accomplishing the same > task is a bad > > idea. I, too, would rather see one mechanism employed-- we > do want to > > create interoperable equipment, after all. Unfortunately, > we already have > > two ways of doing "call hold"-- H.450.4 and "empty > capability sets" (see > > 7.6.2 of Annex F). > > > > The issues you raise with supplementary services echoes the > concerns of > > those also participating in the TIPHON work. Essentially, > service providers > > would like to be able to add new services without upgrading > software in the > > endpoints. Although it may be possible to upgrade IP phone > devices, I can > > assure you that the average person would never do that-- > once the phone is > > plugged in, it will stay there until it stops working. > More importantly, > > why would one want to require somebody who purchased a > hardware phone device > > to upgrade periodically? > > > > We need to engineer a solution so that the telephony > service providers can > > introduce new services without requiring software upgrades > in the endpoints. > > I would like to see SET device to take advantage of those > newly introduced > > services without software or hardware upgrades. > > > > Paul > > > > -----Original Message----- > > From: Derks, Frank <F.Derks(a)PBC.BE.PHILIPS.COM> > > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > > Date: Monday, March 22, 1999 5:45 AM > > Subject: Re: AW: Call hold and transfer in H.323 AnnexF. > Too limited?? > > > > >Folks, > > > > > >when talking about a Simple Endpoint Type, I think we > should aim for it to > > >be something that closely resembles a black phone. This > way it becomes a > > lot > > >easier to define what its capabilities are and it makes > life easy on the > > >users and on those companies that will actually make > (physical) IP-phones. > > >These phones should probably look and act like the normal > phones that are > > >currently being used. Looking at how most supplementary > services are > > >accessed in both the public and the private (PBX) > networks, I think it is > > >safe to say that in most cases we are talking about > "stimulus protocols". > > >I.e. DTMF digits are sent to an exchange and the exchange > interprets > > certain > > >digit sequences as being the invocation of some service > rather than a > > number > > >to be dialled. The big advantage over functional protocols > (like H.450.x) > > >being that services can be added from the exchange side, > without the > > >terminal having to be modified as well. > > > > > >Functional protocols never became a success in the ISDN > world and this may > > >end up to be the same in the IP world. However, having > said this, there is > > a > > >lot more potential for easy upgrading of e.g. terminal > software in this > > >domain, which reduces the side effects of functional protocols. > > > > > >It does not seem to make sense to define "alternative" > mechanisms to > > provide > > >services, so I would strongly opt for using H.450.x when > possible and using > > >a simple stimulus protocol otherwise. The latter would > allow service > > >providers to easily make services available and I see no > reason why this > > >should be standardised. In practice, today, we already see > that certain > > >digit sequences for service activation are identical in > several countries. > > > > > >Frank > > > > > >----------------------------------------------------- > > >Frank Derks |Tel +31 35 6893238 | > > >Advanced Development |Fax +31 35 6891030 | > > >Philip Business Communications |P.O. Box 32 | > > > |1200 JD Hilversum | > > > |The Netherlands | > > >----------------------------------------------------| > > >E-mail: mailto:f.derks@pbc.be.philips.com | > > >WWW: http://www.business-comms.be.philips.com | > > >----------------------------------------------------- > > > > > > > > > > > >-----Original Message----- > > >From: Klaghofer Karl ICN IB NL IP 7 > > >[mailto:Karl.Klaghofer@ICN.SIEMENS.DE] > > >Sent: 18 March 1999 22:36 > > >To: ITU-SG16(a)MAILBAG.INTEL.COM > > >Subject: AW: AW: Call hold and transfer in H.323 AnnexF. > Too limited?? > > > > > > > > >See comment below. > > > > > >Karl > > > > > >> -----Ursprüngliche Nachricht----- > > >> Von: Paul E. Jones [SMTP:paul.jones@TIES.ITU.INT] > > >> Gesendet am: Donnerstag, 18. März 1999 18:57 > > >> An: ITU-SG16(a)mailbag.cps.intel.com > > >> Betreff: Re: AW: Call hold and transfer in H.323 AnnexF. Too > > >> limited?? > > >> > > >> Karl, > > >> > > >> Unfortunately, I will have to disagree with your > comments. While it is > > >> true > > >> that the H.450 supplementary services could be utilized > in a SET device, > > I > > >> believe that introducing H.450 into a SET breaks the > spirit of that work. > > >> > > >> The goal of Annex F is to define a "Simple Endpoint > Type". There are > > >> simpler ways to put a call on hold and to transfer a > call. Introducing > > >> H.450 introduces a lot more complexity that I believe we > want to have. > > If > > >> Annex F is not sufficiently clear on how to simply > transfer a call or put > > >> a > > >> call on hold, we should work on that text-- I will > absolutely disagree > > >> with > > >> introducing H.450 into a SET device. > > > [Klaghofer, Karl PN VS LP3] Whatever you mean with > > "introducing" - > > >H.450 as I sayd in my previous mail is a way of providing > supplementary > > >services like call hold and call transfer to a SET device. > It IS already > > >part of the H.323 Annex F! > > >> Paul > > >> > > >> -----Original Message----- > > >> From: Klaghofer Karl ICN IB NL IP 7 > <Karl.Klaghofer(a)ICN.SIEMENS.DE> > > >> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > > >> Date: Wednesday, March 17, 1999 3:27 PM > > >> Subject: AW: Call hold and transfer in H.323 AnnexF. Too > limited?? > > >> > > >> > > >> >Gunnar, > > >> > > > >> >You are referring to call hold and transfer in > conjunction with H.323 > > >> Annex > > >> >F SETs (Audio or Text) and clause 7.6 of H.323 Annex F. > > >> > > > >> >Talking about call hold, clause 7.6 of H.323 Annex F is > not needed for a > > >> SET > > >> >at all. Call Hold works for a SET as it is defined in H.450.4. > > >> > > > >> >Talking about Call Transfer, clause 7.6 of H.323 Annex > F is not needed > > >> for > > >> a > > >> >SET, if the transfer is executed by the endpoints as > defined in H.450.2. > > >> >Codec re-negotiation you are referring to is no problem > and takes place > > >> >between the transferred and the transferred-to > endpoint. This may cover > > >> your > > >> >case with wireless endpoints being involved. > > >> > > > >> >For call transfer, section 7.6 of H.323 Annex F is only > needed if the > > >> >gatekeeper or a proxy acts on behalf of the transferred > SET endpoint B. > > >> >However, media re-negotiation also should work here as > part of the > > >> fastStart > > >> >method. > > >> > > > >> >Regards, > > >> >Karl > > >> >------------------------------------------------ > > >> >Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL IP7 > > >> >Hofmannstr. 51, D-81359 Munich, Germany > > >> >Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 > > >> >e-mail: karl.klaghofer(a)icn.siemens.de > > >> > > > >> > > > >> > > > >> >> -----Ursprüngliche Nachricht----- > > >> >> Von: Gunnar Hellstrom [SMTP:gunnar.hellstrom@OMNITOR.SE] > > >> >> Gesendet am: Dienstag, 16. März 1999 23:01 > > >> >> An: ITU-SG16(a)mailbag.cps.intel.com > > >> >> Betreff: Call hold and transfer in H.323 AnnexF. > Too limited?? > > >> >> > > >> >> Dear multimedia experts. > > >> >> > > >> >> In my efforts to establish the simple IP voice and > text telephone Text > > >> >> SET, > > >> >> I came across a section in H.323 Annex F (Simple > Endpoint Type, TD11 > > in > > >> >> Monterey) that I feel is causing a functional > obstacle also to the > > >> voice > > >> >> users. Can anyone clarify if I am correct and why it > is specified the > > >> way > > >> >> it is. > > >> >> > > >> >> In section 7.6.1 and 7.6.2 it is specified:" The > Audio SET device > > >> shall > > >> >> then resume transmitting its media stream(s) to the transport > > >> address(es) > > >> >> newly indicated in the OpenLogicalChannel structures." > > >> >> I understand that this means that you cannot > re-negotiate audio > > coding, > > >> >> and > > >> >> you cannot add text conversation after rerouting the > call from a Voice > > >> >> only > > >> >> SET to a Text SET. > > >> >> > > >> >> Re-negotiating the audio coding will probably be a > desired function, > > >> e.g. > > >> >> when rerouting from a fixed to a wireless IP phone. > > >> >> Adding a data channel for text will also be a desired > function, after > > >> >> answering a call in an audio-only SET, and then > rerouting it to a > > >> >> text-capable SET. > > >> >> That action is very common in today's text telephone > usage, and I > > would > > >> >> expect it to be just as common in the IP telephony > world. You first > > >> >> receive > > >> >> the call in the terminal that is closest to you, and > then you get a > > >> reason > > >> >> to start text mode. Then you transfer the call to > another device with > > >> text > > >> >> capabilities, where you can switch mode. > > >> >> > > >> >> Questions: > > >> >> > > >> >> 1. Is that kind of call transfer that is handled by > the mechanisms in > > >> 7.61 > > >> >> and 7.6.2? > > >> >> > > >> >> 2. Are my conclusion right about the limitations? > > >> >> > > >> >> 3. Is this limitation a consequence of using Fast Connect? > > >> >> > > >> >> 4. Do you see any possibility to avoid the negative > effects of it - to > > >> >> make > > >> >> re-negotiation possible? > > >> >> > > >> >> 5. Is the specified functionality acceptable in the > voice world? If > > two > > >> >> devices have agreed on a voice coder, is it likely > that the third > > >> device > > >> >> supports it? Will this not create a lot of > unsuccessful call transfers > > >> >> where the users will have a no chance to understand > why they fail? > > >> >> > > >> >> ---- > > >> >> > > >> >> Another question area: > > >> >> > > >> >> 6. When selecting the transport protocol for the text > conversation, > > the > > >> >> current draft (APC 1504) specifies TCP or UDP. I > realize that there > > are > > >> >> situations where TCP must be avoided. One such situation is a > > >> sub-titled > > >> >> H.332 transmission. Also other multi-casting > situations is better off > > >> with > > >> >> a UDP based transport protocol. > > >> >> I am therfore now leaning towards using RTP as the > transport for text > > >> >> conversation. With RTP we can discover dropped frames > and possibly > > >> invent > > >> >> a > > >> >> mechanism to mark that event in the text stream for > T.140 to display. > > >> If > > >> >> we > > >> >> have less than 3 % dropped frames, I think the users > would accept it. > > >> >> > > >> >> 6.1 Do you agree that there are situations when TCP > should be avoided, > > >> and > > >> >> a UDP based protocol preferred? > > >> >> > > >> >> 6.2 Do you agree that RTP is a good alternative, with > a thin protocol > > >> for > > >> >> error indications to the user? > > >> >> > > >> >> 6.3 Most packets will carry only 1-4 characters . Can > anyone give me > > an > > >> >> indication on the expected packet loss rates in > different situations > > >> for > > >> >> such packets. Or a document giving such figures. Is > max 3% loss > > >> reachable? > > >> >> > > >> >> Please give your view on these questions. > > >> >> > > >> >> Best regards > > >> >> > > >> >> Gunnar Hellström > > >> >> ----------------------------------------------- > > >> >> Gunnar Hellstrom > > >> >> Representing Ericsson in ITU-T > > >> >> > > >> >> E-mail gunnar.hellstrom(a)omnitor.se > > >> >> Tel +46 751 100 501 > > >> >> fax +46 8 556 002 06 > ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************

1 0