Subject: Re: Supplying only a port on a ServiceChangeAddress

From: Naren Tulpule <[email-masked]>
Date: Tue, 29 Aug 2000 15:40:40 -0700

Hi Brian, List,
  people had posed this question (what the format of ServiceChangeAddress
should be) earlier on the list. The answer you gave was
"The address has to make sense in the domain of the transport mechanism. I'm
not too fond of overspecifying this kind of thing, because it requires
changes when you allow additional transports."
I agree with this, upto a point. (e.g. in the case you mention below, "port
number only" should be allowed because it does make sense).

In ABNF ServiceChangeAddress  is specified as VALUE (= 1*(Safe character) /
quotedString). This is useless unless you have enough contextual information
to contact the new address. Flemming's response quotes the text ("in the
context of the current association being negotiated") but that can mean
several things. Why should the parser assume IP transport, for example, and
interprete the number as a port number?

Instead, can we make ServiceChangeAddress  = MID and allow port number in
MID (along with any new transports that may come up). Or it can be "MID or
port number" if you don't want to extend MID. I think it's better to extend
the ABNF for ServiceChangeAddress  later as and when new transports are
added; rather than make it so generalized right now that you can't even
parse it without having additional information about the transport from
somewhere outside the parser.

-- Naren.
Narendra C. Tulpule    SMTS, Trillium Digital Systems
Ph: +1-310-442-9222              Fax: +1-310-442-1162
12100 Wilshire Bl #1800         Los Angeles, CA 90025

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, August 29, 2000 3:04 PM
To: [email-masked]
Subject: Supplying only a port on a ServiceChangeAddress

Suppose all you want to specify in a ServiceChangeAddress is a port number
that is, the IP address doesn't change, but the port does.

The ABNF sez:
serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE

This is because it could be IP, ATM, FR, MPLS....

The example shows just a port number.

Should that be legal?  Should you have to specify the IP address
as x.x.x.x:p?

Brian

---

From: Bharat Kaul <[email-masked]>
Date: Tue, 29 Aug 2000 16:17:16 -0700

Brian,

I have a question here regarding multiple IP addresses. Does MEGACO follow
same retransmission algorithm as RFC 2705 with max1 and max2 as thresholds
and contacting DNS in between as required ? The Megaco document doesn't seem
to say that except a casual mention in D.1.5 section.

If the retransmission algorithm doesn't have max1 and max2 thresholds, are
multiple IP addresses of any significance for communication between a MG and
an MGC with no clear way defined for switching between IP Addresses ?

On a similar note, are we required to maintain TTL for IP addresses and
contact DNS in MEGACO too ?

  Thanks
- Bharat

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, August 29, 2000 3:38 PM
To: [email-masked]
Subject: Re: Supplying only a port on a ServiceChangeAddress

I think the issue is that you can have the same MGC have multiple
IP addresses.  You accept the association, but change the address.
Say, a pool of servers appearing to be one MGC.

Brian

> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Tuesday, August 29, 2000 6:38 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
>
>
> "Rosen, Brian" wrote:
>
> Actually, I thought that's all that would be allowed in the
> case of IP. If
> not, how can it be within the "context of the association
> currently being
> negotiated", and how would it then relate to ServiceChangeMgcId ?
>
> -- Flemming
>
> >
> >
> --
> Flemming Andreasen
> Cisco Systems

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 29 Aug 2000 19:44:21 -0400

I thought you might say that, I've been thinking about it
since I sent the message.

Posing the question slightly differently, if the ServiceChangeAddress
can do what ServiceChangeMid can do, so why have two mechanisms?
The only difference would be the MGs actions.  If you used
ServiceChangeAddress,
the MG would not send a new ServiceChange command to the new address.
If you used ServiceChangeMid, it would.  The end result would be the same.

We can:
        Explicitly disallow ServiceChangeAddress from being used to
                change anything but IP Port when used with IP
        Get rid of one of the two of them

I favor the former, as that is easiest, is most consistent with
history, and makes the most sense to me.  I'll note that what
we call ServiceChangeAddress used to be "port".  It got
changed when we realized "port" wouldn't make sense if it was
not an IP transport.

Brian

> Sent: Tuesday, August 29, 2000 7:37 PM
> To: Rosen, Brian
> I'm not sure I fully understand what an association is then.
> What's the
> difference/relationship between the association address and the
> ServiceChangeMgcId (which may itself contain an address or indirectly
> refer to a number of addresses through DNS) ?
>
> -- Flemming
>
>
> >
> >
> > Brian
> >

---

From: Michael P DiGioia <[email-masked]>
Date: Tue, 29 Aug 2000 20:29:22 -0400

Brian,

>>Suppose all you want to specify in a ServiceChangeAddress is a port numbe

Any one port number alone is useless unless its associated with an
address. However, I believe its valid syntax to allow only the
"portNumber = UINT16" in the ServiceChangeAddress.

/mpd

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 29 Aug 2000 20:38:15 -0400

Changing port only is the normal case.

The MG contacts the MGC on the default port, the MGC replies with a
ServiceChangeAddress with the port it wants this association to use.
It will never be the default port, unless it can only support one MG!

Normally, the address does not change.

Brian

> From: Michael P DiGioia [mailto:[email-masked]]
> Sent: Tuesday, August 29, 2000 8:29 PM
> To: [email-masked]; Rosen, Brian