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

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