Subject: RE: Implementors' Guide Update Editor's last Call

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 11 May 2001 10:03:41 -0400

Maybe "The procedures in Annex D.1 contain a minimum suggested set of
ALF behaviors".

D.1 does not use shall or must very much.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Thursday, May 10, 2001 10:00 PM
> To: Paul Long
> Cc: megaco ietf
> Subject: Re: Implementors' Guide Update Editor's last Call
> 
> 
> G'Day Paul,
> 
> These additions look OK to me with the following comments:
> ALF not defined:
> The note you propose should be in D.1 I've also modified the text:
> "ALF is a set of techniques that allow an application, as opposed to a
> stack, to affect how messages are sent to the other side. A 
> typical ALF
> technique is to allow an application to change the order of messages
> sent when there is a queue AFTER it has queued them.  There 
> is no formal
> specification for ALF. The procedures in Annex D.1 define ALF 
> behaviour
> for the H.248 protocol."
> 
> Source Address:
> Added a "For example" at the front of the changed line. 
> Section 9 we've
> tried to keep as transport independent as possible.
> 
> TimeStamp in registration request and reply:
> I've added this to the existing 6.58 correction.
> 
> Error Descriptor location:
> I've added this to the existing 6.33 correction.
> 
> Cheers, Christian
> 
> 
> 
> Paul Long wrote:
> > 
> > Christian,
> > 
> > I've got a few more additions. Is it too late? These are 
> mostly just a
> > summary of the things I've had resolved recently on the 
> reflector. Here are
> > HTML and Word pages of the same content. (The HTML page 
> doesn't render too
> > well using Netscape. I guess because it was generated by Word. :-)
> > 
> > http://www.packetizer.com/people/plong/IGContribs.htm
> > http://www.packetizer.com/people/plong/IGContribs.doc
> > 
> > Paul Long
> > ipDialog, Inc.
> > 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of 
> Christian Groves
> > Sent: Wednesday, May 09, 2001 12:40 AM
> > To: megaco ietf
> > Cc: Tom-PT Taylor; Glen Freundlich
> > Subject: Implementors' Guide Update Editor's last Call
> > 
> > G'Day all,
> > 
> > The H.248 Series Implementors' Guide has been updated to revision 6.
> > 
> > It can be found at:
> > ftp://standard.pictel.com/avc-site/Incoming/
> > files:
> > TD-xxx_H248_Implementors_Additions_v6.doc
> > TD-xxx_H248_Implementors_Additions_v6.pdf
> > 
> > This revision contains the Approved Implementors' Guide and the
> > Implementors' Guide Additions v5 with some other changes. 
> The changes
> > are detailed in the document.
> > 
> > This is an editors' last call. Please provide comments on 
> this draft by
> > Monday the 13th as a revision 7 will be stored on the 14th 
> and sent to
> > SG16 for approval at the Porto Seguro meeting. If you have 
> a comment on
> > a correction please provide the detailed solution or exact 
> changes that
> > you would like to see.
> > 
> > Cheers, Christian
> 
>

---

From: Dan Elbert <[email-masked]>
Date: Fri, 11 May 2001 09:34:35 -0500

Can we have this in the Implementor's Guide ?
 
-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Wednesday, April 11, 2001 12:06 AM
To: 'Dan Elbert'; [email-masked]'
Subject: RE: Use of "strict" parameter [FINAL?]
 
We only had one comment, from Nurit Shenhar.  He and you are the consensus:
"state" is default, and the "init" parameter MUST be reported back when
strict is set to state.
 
 -----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Thursday, April 05, 2001 11:38 AM
To: [email-masked]'
Subject: RE: Use of "strict" parameter
Hi
Any conclusion in this issue ? Seems like a candidate for causing
interoperability problems...
-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Tuesday, March 13, 2001 10:37 AM
To: 'Dan Elbert'; [email-masked]'
Subject: RE: Use of "strict" parameter
Hi.  Answers below. 
> From: Dan Elbert [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Friday, March 02, 2001 12:17 PM 
> To: [email-masked]' 
> Subject: Use of "strict" parameter 
> 
> 
> Hi All 
> 
> 1. What is the default behavior of the MG if the "strict" 
> parameter is not 
> set ( for events onhook, offhook of al package) ? 
> I'd suggest "state" since this allows to convey the maximal 
> information back 
> to the MGC. 
[PTT] We should choose whatever reflects the most frequent usage -- defaults
are there to save effort.  For people who don't want to look it up, "state"
means that if a line is already on/off-hook when told to watch for
on/off-hook, the corresponding state transition event will be reported.
Does this seem like the most likely setting?
> 
> 2. What is the correct use of the "exact" value for the 
> "strict" parameter ? 
> If the termination is already in the required state, I 
> understand that 
> this setting will cause the termination not to send the event 
> but to keep 
> waiting for it. Is this correct ? Seems like in this case there is 
> a risk of the MGC getting out of synch with the MG. 
[PTT] 
Your description of behaviour is correct.  There could be circumstances
where the MGC wants to use this one, for instance, to tell the MG to watch
for off-hook as a final step of call cleardown, where the line may still be
off-hook from the previous call.
> 
> 3. If the "init" parameter is not set when reporting a hook 
> event, should 
> this be considered the same as if it was set to "False" ? 
> (this is what makes more sense to me). Or is this a required 
> parameter ? (I 
> don't think that anybody was setting this in the interop...) 
[PTT] 
We need agreement on this, particularly when the "state" setting is used.
Comments, people? 
> Thanks, 
> Dan Elbert

---

From: "Kaul, Bharat" <[email-masked]>
Date: Fri, 11 May 2001 11:54:43 -0700

Paul,

Effectively yes..MG shouldn't have a TCP server for Version 1.0 of the
protocol. MG having a TCP server doesn't mean anything as MGC are not
supposed to have capability to initiate connections.

Currently MGs contact MGC and then they communicate. This implies
essentially MGC doesn't need to have the capability to contact MGC.
Outlining the same in the standards keeps life simple as MGC don't need to
deal with these possibilities and build intelligence to initiate
connections. 

Instead of taking an approach where, "if you can't do something, don't
signal that you can",  I think it should be if you want to use a particular
port in TCP, open your connection from there.  And MGs are fully capable of
doing so.

And I am not so sure that protocal can remain indifferent to underlying
protocol. Our retransmission strategies for should be different for TCP and
UDP. And similarly tomorrow with SCTP in picture, suddenly we need to deal
with associations and streams.

- Bharat

-----Original Message-----
From: Paul Long [mailto:[email-masked]]
Sent: Friday, May 11, 2001 10:50 AM
To: megaco ietf
Subject: RE: Implementors' Guide Update Editor's last Call

Bharat,

But if an MG specified a ServiceChangeAddress, that would imply that it
would indeed be able to listen on that port for a TCP connection to be
established. I just don't understand why we need to constrain something in
the standard that will naturally be controlled by the signaling entity.
Basically, if you can't do something, don't signal that you can. Maybe you
are saying that an MG cannot inherently ever be a "TCP server." Is that it?
If so, why can't it?

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Kaul, Bharat
Sent: Friday, May 11, 2001 12:33 PM
To: 'Christian Groves'; Paul Long
Cc: megaco ietf
Subject: RE: Implementors' Guide Update Editor's last Call

Hi Paul,

  For 6.58 in implementation guide the reason it is UDP only is that for an
MG using TCP as transport it is of no use to have ServiceChange Address
specified in it as MG does not have a TCP server where MGC will connect to.
This implies  for TCP as transport MGC should not look at ServiceChange
Address either. The standards didn't say any of this anywhere and there is a
whole series of emails on this indicating possibility of interop issues. And
in order to end this silence of the standards, the part was added in
implementors guide.

- Bharat