Global Call Reference Value

Paul E. Jones paulej at PACKETIZER.COM
Thu Dec 7 00:57:18 EST 2000


Logan,

I believe the right approach for the Facility for the purposes of changing the multipleCalls flag is to use empty.  As you may recall, the reason for not wanting to use empty for other messages is so that the CallIdentifier is made available.  In this case, the Facility message is being used outside the context of a call.

I don't count this one as such a critical issue, but we need to correct the error nonetheless.  This should be clarified with a simple addition to H.323 that specifically suggests using empty in this case.  H.225.0v4 may also need a change if it does say the use of empty is forbidden.

Paul

  ----- Original Message ----- 
  From: Logan Modahala 
  To: ITU-SG16 at mailbag.cps.intel.com 
  Sent: Wednesday, December 06, 2000 11:55 PM
  Subject: Re: Global Call Reference Value


  Paul, 
  That's yet another inconsistency. If you use Global CRV in Facility for "multipleCalls" the only way you can 
  do is using "empty" but that is disallowed and hence Facility-UUIE must be used. In which case we cannot include a "CallIdentifier". But CallIdentifier is NOT OPTIONAL. Same with Status and Status Inquire as well with "multipleCalls". 

  My take is that "empty" makes sense there but I know others don't like "empty".  Otherwise, we need to come up with a "DUMMY Call Identifier" for thsi purpose. 

  - Logan. 
    

  "Paul E. Jones" wrote: 

    Folks, In H.225.0v4, there are several references to the Global Call Reference value.  It is described in H.323v4 how it is used for Facility to signal changes in the "multipleCalls" state and in IRQ to indicate a request for information for all calls.  However, what is the use for it in Status and Status Inquiry? Also, for the Facility message, how shall the CallIdentifier be coded, since the Facility-UUIE is now required? Paul 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20001207/4ebd263f/attachment-0004.html>


More information about the sg16-avd mailing list