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

From: [email-masked]
Date: Wed, 25 Jun 2003 15:11:24 +0800

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

---

From: [email-masked]
Date: Fri, 27 Jun 2003 10:50:17 +0800

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 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,
>gagagagaco
>  https://www1.ietf.org/mailman/lis1�r���X��X��?
> i?z��m��??0?�~���f��f��X��)ߣ����(

z��f��)��+-1�r����+�m����5��_��?�������+-�w��g�i�

---

From: [email-masked]
Date: Fri, 27 Jun 2003 10:50:17 +0800

Hi,all

   Best regards,
   Zichun

the
divide
that you
That is a
need some way

                    Aleksandr                                                               
                                                                                            
                    2003-06-26                                                              
                    23:14                                                                   

Hi,

Regards,
         Aleks

But
MGW.
machine
process
problem,
unlike
M3UA
etc)