Subject: Re: Addressing For Control

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 4 Sep 2000 20:51:45 -0400

I have responses to some of your comments.

> -----Original Message-----
> From: Bharat Kaul [mailto:[email-masked]]
> Sent: Friday, September 01, 2000 7:20 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH];
> [email-masked]
> Subject: RE: Addressing For Control
>
>
> Hi Tom,
>
>   My comments are below
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Friday, September 01, 2000 12:01 PM
> To: [email-masked]
> Subject: Addressing For Control
>
> 2. (?) The role of the MId in the message header is to provide
> application-level identification of the sender of the
> message.  In any given
> control session, the MId used by a given end will stay the
> same, even if the
> transport connection changes.  MIds for different virtual MGs
> will differ,
> even if they reside at the same IP address.
[PTT: my incorrect statement at the end of this para snipped to avoid
confusion]
>
> [[ BHARAT ]]
>
> We should have a simple statement which says MID is unique
> for a control
> session for a megaco component. This should cover MGCs, MGs
> and virtual MGs.
[PTT] That's the intent.

>
>
> MG-Originated ServiceChange
> ===========================
>
>
> 4. If the MG issues a ServiceChange on ROOT, the
> ServiceChangeAddress MAY be
> present in the request.  If so, it provides the address to
> which the MGC is
> meant to send all requests that it issues within the current control
> session.  Where TCP is in use, this means the following
> sequence will occur:
>
>    (a) MG sends ServiceChange from TCP addr:port A, containing
> ServiceChangeAddress equal to addr:port B (understood to be
> TCP because the
> original contact was via TCP).
>
>    (b) MGC sends its response on the TCP connection to addr:port A.
>
>    (c) MGC opens up a TCP connection to addr:port B and sends
> all subsequent
> requests through that connection.  The MG returns its
> responses to the MGC's
> requests through the same connection.
>
> [[[[ BHARAT  ]]]]]]
>
> I don't think (c) should be an option. First because of security
> arrangements, secondly because MGs already have a capability
> of initiating
> connections and let them keep on
> doing so. This need not be part of MGCs. Also, I can't see
> why MG would want
> to specify
> a ServiceChange Address for TCP. It might as well initiate
> the connection
> using that source transport address where it wants to
> communicate. I am
> inclined towards not having (c) as an option for TCP.(c)
> however is a valid
> option for UDP.
[PTT] (a), (b), and (c) are not alternatives -- they must all happen IF the
MG sends a ServiceChangeAddress on a TCP connection.  If one doesn't want to
support that sort of behaviour then one's MG should be designed not to
initiate it.  I suppose that as a stack provider you may find yourself in an
awkward position on this, but you'll have to work it out with your
customers.

>
>
>
>
> 6. In a ServiceChange response, the MGC may provide a
> ServiceChangeAddress,
> a ServiceChangeMGCId, or neither.
>
> [[[[ BHARAT ]]]]]
>
> I hope you mean ServiceChangeAddress OR ServiceChangeMGCID not both.
[PTT] Yes, I do.
>
>
>
> MGC-Originated ServiceChange Request
> ====================================
>
> 9. The MGC may originate a ServiceChange request containing
> ServiceChangeAddress.  This requires the MG to take the
> following actions:
>
>     (a) as above
>
>     (b) send all subsequent requests to the indicated
> ServiceChangeAddress
>
>     (c) if retransmitting outstanding requests to the MGC,
> use the same
> address that the original request went to.
>
> It seems reasonable to require that in this case the
> ServiceChangeMethod (if
> any) should be restricted to GRACEFUL or FORCED.
>
> [[[[[ BHARAT ]]]]]]
>
> I am not sure I understand what MGC is trying to tell MG
> while using these
> methods. Specifying ServiceChangeAddress after things are up
> and running
> (i.e. registration has
> completed long back) might be tricky with TCP as transport.
> It would be
> interesting to see what people have to say on this. Till now,
> I thought only
> "handoff" is the allowed method from MGC to MG.
>
[PTT] I invite further comments.

> - Bharat

---

From: Shalini Philip <[email-masked]>
Date: Tue, 5 Sep 2000 13:37:53 +0530

Hello Tom, list,

    Please find my comments to point 9 below.

> [PTT] I invite further comments.

In case of TCP and UDP, if after successful registration, the MGC wants to
change the port on which
communication happens with MG, it can always send a Service Change command
Request with service
change method as "Handoff" and a ServiceChangeMgcId as the new MgcId (with the
new port information).

Another point that I would like to make is that even FORCED or GRACEFUL on ROOT
can be possible service change methods from MGC -> MG,
in case there is no backup MGCId to which handoff can happen. In such a
situation, the MG should try registration with any
other MGC in its provisioned list of primary and secondary MGCs.

--
Regards,

Shalini Philip
Globespan Inc.
E-Mail : mailto:[email-masked]
Web    : http://www.globespan.net