Subject: [Megaco] 答复: Re: [Megaco] A question about H.248 onSCTP

From: [email-masked]
Date: Thu, 26 Jun 2003 16:26:24 +0800

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
>

1�r���X��X��Ǡi�"z��m��?�0�'�~���f��f��X��)ߣ����(

---

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 26 Jun 2003 11:14:20 -0400

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 
> Taylor
>                     <taylor@nortelnet       ÊÕ¼þÈË£º 
> [email-masked]
>                     works.com>              ³ËÍ£º  [email-masked] 
>
>                                             Ö÷Ìâ£º  Re: [Megaco] A 
> question about H.248 on
>                                              SCTP 
>
> 
>
>                     2003-06-26 
> 01:19
> 
>
> 
>
>
>
>
>
>
>gagagagaco
>  https://www1.ietf.org/mailman/lis1èr‰šŠX§‚X¬´Ç 
> iÊ"z×è®m¶›?ÿ0Ö'~Šàþf¢f§þX¬¶)ß£ùž§(

---

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 26 Jun 2003 11:14:20 -0400

Hi,

Regards,
         Aleks