Subject: Re: [Megaco] A question about H.248 on SCTP

From: Qiaobing Xie <[email-masked]>
Date: Mon, 11 Aug 2003 16:35:22 -0500

A late response to an old email... My comments in-line.

[email-masked] wrote:
> 
> Hi,all
>    As Tom said,I agree we can split a MGW into several virtual MGWs to
> solve huge MGW problem.
>    As Aleks said, I agree the transport connection type of
> TCP/UDP/SCTP/MTP3B/M3UA are of no difference.
>    Maybe may question should be renamed to How H.248 be used in big system,
> not only about SCTP transport connections.
>    The problem is: how many transport connection should exist bewteen a
> pair MGC-MGW? The MGC's servicechange transaction can provide only one
> IP+PORT(etc.) indication. If the answer is only one connection such as
> TCP/SCTP could exist between MGC-MGW pair, since hardware capacity is
> limited one connection can provide limited H.248 transaction delivery
> ability. In 3GPP when we design big MGW system, one connection capacity is
> not efficient. One word, must we split the MGW into several little systems
> to provide several logical interface to MGC? I think It's inconvenient for
> system maintenance and evolvement.

I think you are asking a system design question. This is a decision
system designer needs to make. If you choose to use multiple connections
(TCP, SCTP, or UDP), you will pay the cost for more complexity in your
application design and system operation and configuration because your
app will need now to manage multiple connections. Using a single
connection simplifies design and I do not see any inherited problem for
doing so. 

For large system, the bigger concern is often the reliability of the
connection since if it fails you will have a large impact. In this
respect, SCTP can potentially give you some advantages over UDP or TCP
due to its multi-homing capability to support redundant NICs and
cabling. Making use of SCTP streams will help avoid head-of-line
blocking problem, but you don't have to do it if head-of-line blocking
is not one of your concerns.

-Qiaobing

>    I think Aleks and Tom didn't recognize my true idea. In my before
> scenario ,the MGC has 2 machines(processor) to process one MGW, these 2
> machines belong to ONE MGC, maybe there are more than one machine on MGW
> too, not in our sight. When 2 or more porcessor existed the processor
> identify is a problem. As Aleks said we can parse the RequestIdentifier to
> identify the processor, but don't u think it waste a lot time, and this
> method cann't let MGC process the calling state termination out of service
> ServiceChange transactions. I insist predefined CONTEXTID between MGC-MGW
> is a better way to solve this problem. Or MEGACO define this:" CONTEXTID is
> predefined on MGW, MGC can audit CONTEXTID from MGW after MGW registering".
> We can get CONTEXTID with few parsing steps. Of course we must deal with
> multi-transactions in one message, this is a easier scanning work compare
> with word to word parsing.
> 
>    I didn't think two MGCs can operate one MGW, a logic MGW should belong
> to one MGC. As MEGACO definition the CONTEXTID is valid between a MGC-MGW
> pair, so the CONTEXTID selected by MGC is possible. The big advantage of
> this rule is let H.248  act like a call related protocol more.
>    I'm confused by Aleks's words: "a message can contain several
> transactions with terminationIds 'serviced' by different MGCs". I think
> this couldn't happen because there should be diffent transport connections
> from different MGCs to a physical MGW(this MGW was splitted to different
> MGWs).
> 
>    Best regards,
>    Zichun
> 
> Tom Taylor <[email-masked]> says:
> 
> >The MGC controls which address and port the MGW sends its Notify to, in
> the
> >ServiceChange reply.  Of course, this is a static arrangement.  You can
> divide
> >things up by splitting the MGW up into virtual machines, but yes, I agree
> that you
> >cannot dynamically loadshare the control of one MGW between two MGCs.
> That is a
> >deliberate constraint in Megaco because dynamic sharing would mean you
> need some way
> >to resolve contention if two MGCs try to use the same resources.
> 
> 
>                     Aleksandr
>                     Ryabin               ÊÕ¼þÈË£º     [email-masked],
>                     <kengr@winphor        [email-masked]
>                     ia.com>              ³ËÍ£º  Tom Taylor <[email-masked]>
>                                          Ö÷Ìâ£º  Re: [Megaco] A question about H.248 on
>                                           SCTP
> 
>                     2003-06-26
>                     23:14
> 
> 
> 
> Hi,
> 
> I'm not exactly following how SCTP differ from UDP, or TCP
> for message distribution problem you are trying to solve,
> but in Notify there is RequestIdentifier which is provided by
> MGC (A or B), thus you can route (on A) based on it,
> that is of course provided you parse whole message on A,
> which you have to do anyway since a message can contain several
> transactions with terminationIds "serviced" by different MGCs
> 
> Regards,
>          Aleks
> 
> At 04:26 AM 6/26/2003, [email-masked] wrote:
> 
> >Tom,
> >   This rule can ensure one side message sequencely arrived at the peer.
> But
> >only the message sequence assurance is not efficient in big systems. Maybe
> >big system is neglected by MEGACO. The problem is the balance between
> >multi-machine. Let's consider the following example:
> >
> >   MGC has 2 machines(A,B) to  process the context transactions for one
> MGW.
> >Since SCTP cann't provide one association on different machines. So there
> >are at least two association on machine A and B. When a context need to be
> >established, the MGC send transactions to MGW through association at
> >machine A. But the MGW may send NOTIFY transactions to MSC through
> >association at machine B. So machine B have to send this message to
> machine
> >A. When MGC have more machines, the message distribution is a mess.
> >
> >   In the TDM call process, ITU defines CIC number for TUP/ISUP processing
> >pair. Since every call is combined with a CIC number, every TUP/ISUP call
> >message bing a CIC, it's easy to let process peers to find the call
> process
> >machine. Also the BICC protocol adopt the CIC to identify call entiy
> >between BICC pair.
> >
> >   It's a pitty there is no similar way in MEGACO. Though MEGACO provide
> >CONTEXTID between MGW/MSC, but unfortunately, the CONTEXTID is dynamiclly
> >allocated by MGW during the call. If the MGW is small, there is no
> problem,
> >because all the CONTEXT is processed by one machine. When the MGW is huge,
> >the incoming MEGACO message distribution is a problem, the MEGACO bearer
> >layer couldn't decide which process machine should get this message,
> unlike
> >TUP/ISUP, the MTP3 can find the process machine by CIC. Only after H.248
> >decode the message, it could find the process machine in a mess.
> >
> >   If we add similar rules like TUP/ISUP, we will solve these problem. I
> >suppose the rule is:
> >
> >   1. "H.248 call CONTEXTID is predefined between MGC and MGW. MGC get a
> >CONTEXTID when a call should be initiated. MGW decide whether the CONTEXT
> >exist or not, if dosn't exist it create a context with this CONTEXTID."
> >This rule is for multi-machine call load balance, and for transport layer
> >easy finding process machine, just like other call related protocol
> >TUP/ISUP/BICC.
> >
> >   2."MGC/MGW SHOULD select transport layer links(such as MTP3B links,
> M3UA
> >ASPs and streams, SCTP associations and streams, TCP links, UDP ports,
> etc)
> >by CONTEXTID lowest 4 bits." This rule is for transaction sequences belong
> >one context, also the load balance of transport layer links.
> >
> >   Best regards.
> >
> >   Zichun
> >
> >
> >
> >
> >
> >
> >
> >
> >                     Tom
> > Taylor
> >                     <taylor@nortelnet       ÊÕ¼þÈË£º
> > [email-masked]
> >                     works.com>              ³ËÍ£º  [email-masked]
> >
> >                                             Ö÷Ìâ£º  Re: [Megaco] A
> > question about H.248 on
> >                                              SCTP
> >
> >
> >
> >                     2003-06-26
> > 01:19
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >It really doesn't matter which stream each end uses, so long as one end
> >uses the
> >same stream for all messages relating to a given context.  The reason for
> >this rule
> >is to ensure that messages arrive in order at the peer.
> >
> >[email-masked] wrote:
> >
> > > Hi,
> > >   H.248.4 (Annex H) gives SCTP to transport H.248 transactions. The
> paper
> > > says: It is recommended that transactions related to one context are
> > > transported over the same stream. SCTP transmits messages and processes
> > > received messages in one stream.
> > >
> > >   When MGC and MG exchange informations. The MG/MGC maybe get context_A
> > > messages from inbound stream_1, but send out context_A messages from
> >inboud
> > > stream_2, the paper didn't tell us the streams MUST be used as pairs:
> > > inboud stream_1 so outbound stream_1.
> > >
> > >   And there maybe coexist more than one SCTP associations between
> >MGC/MGW.
> > > The MG/MGC maybe get contex_A messages from one association and respond
> >the
> > > reply in another association. The paper din't tell us MUST use one
> > > association to process one context.
> > >
> > >   The upper mechanism is different from TUP/ISUP call process. The
> MGC/MG
> > > couldn't anticipate the H.248 communication partner reply the call
> >context
> > > message in which association or stream. If the MGC initiate a context
> in
> > > one association ,but received reply in another association, MGC have to
> > > forward the message to the initiated place. Doesn't it looks strange?
> >Maybe
> > > u have further suggestion about this question.
> > >
> > >   Thanks.
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Megaco mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/megaco
> > >
> >
> >
> >
> >gagagagaco
> > >
> >
> >
> >
> >  https://www1.ietf.org/mailman/lis1èr‰šŠX§‚X¬´?
> > i?z×è®m¶›??0?~Šàþf¢f§þX¬¶)ß£ùž§(
> 
> 1è

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 11 Aug 2003 16:35:22 -0500

-Qiaobing