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

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

Agreed ...that is a good suggestion :)

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

Bharat,

Someone just told me via private email that the problem isn't necessarily
with the MG but with the MGC. We don't want to require the MGC to ever have
to initiate a connection to the MG, and this would otherwise be the only
situation where it would have to. I don't have to understand why, I'll just
assume that there are real good reasons. :-)

How about changing the wording, then. I thought the original sentence was
kind of awkward, anyway. How about changing from this:

"For UDP as a transport, the MG may specify the transport
ServiceChangeAddress to be used by the MGC for sending messages in the
ServiceChangeAddress parameter in the input ServiceChangeDescriptor."

to this:

"In the ServiceChangeAddress parameter of the ServiceChangeDescriptor, the
MG may specify the transport address to be used by the MGC for sending
request messages.  So that the MGC does not have to initiate a new
connection, however, the MG shall not specify a ServiceChangeAddress if the
association is using a reliable, connection-oriented transport."

This explains the requirement somewhat and eliminates the reference to a
particular transport. I would have just said, "connection-oriented
protocol," since that would mean TCP in the case of IP, but that term is not
used elsewhere in the spec, so I also said "reliable." From a quick online
search, it appears that "reliable" and "connection-oriented" are synonymous,
but we can state both just to be absolutely clear. What do you think about
this new wording?

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Paul Long
Sent: Friday, May 11, 2001 12:50 PM
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

---

From: Chuong Nguyen <[email-masked]>
Date: Fri, 11 May 2001 16:22:23 -0500

Do we also need words for the Reply by MGC?

--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: "Paul Long" <[email-masked]>
Date: Fri, 11 May 2001 16:42:46 -0500

Chuong,

I was under the impression that the MG is always able to establish a
connection. Therefore, the MGC may specify a ServiceChangeAddress regardless
of whether it is using a connection-oriented or connectionless transport for
a given association. An MG must therefore always be able to close the
current connection and establish a new one upon receipt of
ServiceChangeAddress from the MGC with a port number that is different than
the current one. Note that the new connection continues the current
association, so re-registration is not appropriate.

Paul Long
ipDialog, Inc.
  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of Chuong Nguyen
  Sent: Friday, May 11, 2001 4:22 PM
  To: Kaul, Bharat
  Cc: 'Paul Long'; megaco ietf
  Subject: Re: Implementors' Guide Update Editor's last Call

    "In the ServiceChangeAddress parameter of the ServiceChangeDescriptor,
the
    MG may specify the transport address to be used by the MGC for sending
    request messages.  So that the MGC does not have to initiate a new
    connection, however, the MG shall not specify a ServiceChangeAddress if
the
    association is using a reliable, connection-oriented transport."

    This explains the requirement somewhat and eliminates the reference to a
    particular transport. I would have just said, "connection-oriented
    protocol," since that would mean TCP in the case of IP, but that term is
not
    used elsewhere in the spec, so I also said "reliable." From a quick
online
    search, it appears that "reliable" and "connection-oriented" are
synonymous,
    but we can state both just to be absolutely clear. What do you think
about
    this new wording?

    Paul Long
    ipDialog, Inc.

---

From: Chuong Nguyen <[email-masked]>
Date: Fri, 11 May 2001 17:27:11 -0500

This goes way back.  I thought some where back (way back in the archive)
for TCP,
it was OK to include ServiceChangeAddress and it would be ignored.

Ok I will go along w/the understanding.
It is just strange that we specify something for MG but not MGC because
there is an
understanding that MG is never the TCP server but MGC is.
So for TCP MGC can specify the ServiceChangeAddress in the Reply but not
MG.

Chuong

Paul Long wrote:

> Chuong,I was under the impression that the MG is always able to
> establish a connection. Therefore, the MGC may specify a
> ServiceChangeAddress regardless of whether it is using a
> connection-oriented or connectionless transport for a given
> association. An MG must therefore always be able to close the current
> connection and establish a new one upon receipt of
> ServiceChangeAddress from the MGC with a port number that is different
> than the current one. Note that the new connection continues the
> current association, so re-registration is not appropriate.Paul
> LongipDialog, Inc.
>

---

From: Christian Groves <[email-masked]>
Date: Mon, 14 May 2001 03:54:19 +1000

G'Day Tom,

Do you want to try a FINAL on this thread? I must say I'm confused what
people want. The line about a MGC never initiating a servicechange has
thrown me.

Cheers, Christian

Chuong Nguyen wrote:
> 
> 
> This goes way back.  I thought some where back (way back in the
> archive) for TCP,
> It is just strange that we specify something for MG but not MGC
> because there is an
> So for TCP MGC can specify the ServiceChangeAddress in the Reply but
> not MG.
> 
> Chuong
> 
> Paul Long wrote:
> 
> > association. An MG must therefore always be able to close the
> > ServiceChangeAddress from the MGC with a port number that is
> > different than the current one. Note that the new connection
> > continues the current association, so re-registration is not
> > appropriate.Paul LongipDialog, Inc.
> >