Subject: RE: Segmentation (was Re: [Megaco] Wildcarded Action Reply)

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 12 Jul 2002 09:58:44 -0400

Well, it seems Christian beat me to the punch, as I was going to suggest we
step back and look at requirements before we decide we have a solution.  I
believe that these are an excellent summary of what it is we're trying to
accomplish.

Kevin

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, July 11, 2002 11:14 PM
To: Aleksandr Ryabin
Cc: [email-masked]
Subject: Re: Segmentation (was Re: [Megaco] Wildcarded Action Reply)

G'Day Aleks,

Segmentation is new functionality, however you try to bend it, it does not
clarify
or fix because when we designed Megaco we were all well aware that
segmentation
wasn't in it. It was given UDP had this problem. If you use ATM transport
then
you don't need to implement UDP. The example you gave of timestamps is not
the
same akin to this topic as timestamps already exist in the core protocol. 

I assume that we are operating in the real world because today segmentation
is
solved "outside" the core protocol. ie. SCTP. We already have a mechanism
(error
code 533) where by the MG can indicate that a response is too large and then
the
MGC can ask for smaller replies. This is effectively what is being proposed
in
the segmentation package.

Let's talk about requirement rather than protocol solution. A start for some
requirements would be:
o provide an efficient means to segment and reassemble H.248 protocol
messages
o provide a means to detect segmentation/reassembly errors
o Minimise protocol overhead in terms of signalling, BW, processing
o Minimise dependencies (maximise transparency) to the Megaco state machine
o Maximise throughput of signalling data

Regards, Christian

Aleksandr Ryabin wrote:
> 
> Hi Christian,
>          Please see below inline [AR] .
> 
> At 02:34 AM 7/11/2002, Christian Groves wrote:
> >G'Day Aleks,
> >
> >Please see my replies below.
> >
> >Regards, Christian
> >
> >Aleksandr Ryabin wrote:
> > >
> > > Hi Christian,
> > >
> > > To address your concern regarding "a new event you modify the
behaviour
> > of the
> > > core protocol" I'd like to point out that there are numerous drafts
out
> > > there that
> > > extend and alter protocol behavior. Thus I think as long as altered
> > > behavior does
> > > not contradict (e.g. breaks) basic protocol functionality, but rather
> > > clarifies how
> > > MGC controls MG that should be fine.
> >
> >[CHG] Could you please point me to these drafts for Megaco? Perhaps the
reason
> >that they are still drafts is that they weren't accepted for approval.
Just
> >because a draft is written and submitted to the IETF doesn't mean that it
is
> >right. For example the call flows document and the association draft, I
> >wouldn't
> >base an implementation on these.
> 
> [AR] Any package which has "Procedures" paragraph does clarify how and
what
> has to be changed in MGC-MG messaging to utilize that package.
> 
> I do not want to go into debate of "what did you precisely mean and why
you
> used it here" :) but as an example in
draft-manyfolks-megaco-caspackage-02.txt:
> 
> "7.6.1 Timestamp Procedures.
> Inclusion of a timestamp in the ObservedEvents descriptor is mandatory for
the
> RBS package. The timestamp reflects the detection time for the event and
may
> be used by services (e.g. automatic message accounting) on the MGC."
> 
> Note how package mandates of inclusion of a timestamp which in core
protocol
> is optional, thus it does modify, or I'd say clarify core protocol
behavior.
> 
> >I don't see that the proposed addition
> >"clarifies", it adds new functionality.
> 
> [AR] Yes it does indeed, as any package does. Although at the same time it
> clarifies and "fixes" usage of core protocol in the place where it has a
flaw.
> 
> > >
> > > I mean for this specific case, where does the the protocol say that MG
has
> > > to return
> > > exactly the same reply to two exactly the same transactions with only
> > > difference
> > > in time sent and transaction ids? Thus MG can possibly return even
> > right now
> > > replies like in examples below (less of course the "split" package
> > stuff), but
> > > the only problem would be for MGC to "assemble" them. Thus "split"
package
> > > approach does not invent here anything, but rather "controls" MG on
> > what and
> > > when to return and that is a primary functionality of MGC, after all
it is
> > > a Media
> > > Gateway Controller :)
> >
> >[CHG] You do not need the "split" package for the MGC to do this. We
already
> >have error code 533 which enables the MGC to requests more atomic
replies.
> 
> [AR] As I already suggested, granularity is not going to work in all the
cases.
> The only case it will work all the time if no wildcards used at all,
which
> is not a best solution in some cases, thus we have this discussion :)
> 
> > >
> > > I'd like to stress a "protocol" solution as I do believe that it has
to be
> > > addressed in
> > > the protocol, not outside of it, as not to have intentional "holes" in
the
> > > protocol.
> > >
> >[CHG] Why? Shouldn't we look at the benefits of such an approach? Less
> >signalling, more timely responses. It seems to me to have it outside the
> >protocol is more natural. SCTP for instance already provides this
service.
> 
> Let me rephrase. I have nothing against using of benefits outside the
protocol.
> In fact I'm very much for it, but in real world when you have a real
> application
> it is not that easy to "fix" a core protocol limitation, by seeking to
patch it
> on outside of a protocol. Sometimes it is easier to switch to some other
> protocol all together :-) You would not just take off and go to Alaska
because
> it is always hot in your home. Instead you will probably first see if you
can
> install an air conditioner :)
> 
> All I'm saying is if a protocol (not specifically MEGACO) defines set of
rules,
> these set of rules (in ideal world) SHELL work all the time. Applying this
> to MEGACO: the protocol defines that UDP transport protocol is mandatory
> for MGC and it defines usage of wildcard, but in a real world this is not
> going
> to work due to limitations of UDP.
> 
> Thanks
>          Aleks
> 
> >..snip..

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 12 Jul 2002 09:58:44 -0400

Kevin

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, July 11, 2002 11:14 PM
To: Aleksandr Ryabin
Cc: [email-masked]
Subject: Re: Segmentation (was Re: [Megaco] Wildcarded Action Reply)

G'Day Aleks,

Regards, Christian

behaviour
out
reason
Just
is
what
you
the
may
protocol
behavior.
flaw.
has
package
it is
already
replies.
cases.
which
to be
the
service.
protocol.
patch it
because
can
rules,

---

From: "Alf Heidermark (EAB)" <[email-masked]>
Date: Mon, 15 Jul 2002 08:30:46 +0200

Hi

I think it is enough to provide a warning, in the specificati related to context ALL. The warning would indicate that the use of context id all may lead to long messages. An implemetation shall take that into account the constraint of the signalling transports. 

Alf

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: den 15 juli 2002 00:31
To: Aleksandr Ryabin
Cc: Christian Groves; [email-masked]
Subject: Re: Segmentation (was Re: [Megaco] Wildcarded Action Reply)

Hi,

I don't think my solution would mean "modifying the protocol", IF the identifier is
defined within a package, within an existing descriptor. Adding a package is NOT
the same as modifying the protocol, it is an extension mechanism within the
protocol.

The package solution WOULD be backward compability, but nodes not supporting the
package would of course not be able to use the feature (the node creating the node
would simply create an error response if the reply is too big to send within one
message, and segmentation is not supported).

HOWEVER, as Christian said, since we DO have transport protocols (TCP and SCTP)
which can be used to solve this issue, I would like to know if anyone has a
scenario where using some of those transport protocols would not solve this issue.
I am not saying I would go as far as making one of those protocols MANDATORY for
AuditXxx commands, but I think it could at least be a RECOMMENDATION... We should
remember that the protocol does not mandate one to use the same transport protocols
for all messages (even if I assume that is what people most often would do...)

Also, no matter what method we will use, I also agree with Christian and Kevin on
the fact that we shall first come up with specific requirements, what exactly we
want to functionality to provide us.

Regards,

Christer Holmberg
Ericsson Finland

Aleksandr Ryabin wrote:

> Hi Christian and folks,
>
> And I'd like to add another several requirements (which might be given,
> or optional, or even questionable, but worth mentioning):
>
> 6. provide backward compatibility
> 7. provide unified solution for all versions of protocol
> 8. provide "application based" message segmentation
>
> Now I'd like to sum what solutions have been proposed so far:
>
> 1. Kevin B.: modify protocol and define descriptor with "sequence number",
> add "end of transaction" token and a "partial ack" token.
>
> 2. Christer H.: modify protocol to include "identifier" to be used to
> reassemble separate transactions.
>
> 3. Aleks R.: Define "split" package to control flow of reply messages
> (obsoleted: define an extension for "enumeration" mechanism).
>
> 4. Christian G.: Use "transport based" message segmentation.
>
> I understand the protocol was designed with no segmentation provisions,
> but so far we have three proposals for "application based" message
> segmentation, which means that req 8 is really important.
> Before going into any further analysis does folks agree on that?
>
> Thanks
>          Aleks
>
> At 11:14 PM 7/11/2002, Christian Groves wrote:
> >G'Day Aleks,
> >
> >wasn't in it. It was given UDP had this problem. If you use ATM transport then
> >you don't need to implement UDP. The example you gave of timestamps is not the
> >I assume that we are operating in the real world because today segmentation is
> >code 533) where by the MG can indicate that a response is too large and
> >then the
> >MGC can ask for smaller replies. This is effectively what is being proposed in
> >o provide an efficient means to segment and reassemble H.248 protocol messages
> > > > > To address your concern regarding "a new event you modify the behaviour
> > > > of the
> > > > > core protocol" I'd like to point out that there are numerous drafts out
> > > > > there that
> > > >[CHG] Could you please point me to these drafts for Megaco? Perhaps
> > the reason
> > > >because a draft is written and submitted to the IETF doesn't mean that
> > it is
> > > [AR] Any package which has "Procedures" paragraph does clarify how and what
> > > I do not want to go into debate of "what did you precisely mean and why you
> > > Inclusion of a timestamp in the ObservedEvents descriptor is mandatory
> > for the
> > > RBS package. The timestamp reflects the detection time for the event
> > and may
> > > clarifies and "fixes" usage of core protocol in the place where it has
> > a flaw.
> > >
> > > > >
> > > > > I mean for this specific case, where does the the protocol say that
> > MG has
> > > > > to return
> > > > > when to return and that is a primary functionality of MGC, after
> > all it is
> > > > > a Media
> > > > > Gateway Controller :)
> > > >
> > > >have error code 533 which enables the MGC to requests more atomic replies.
> > >
> > > [AR] As I already suggested, granularity is not going to work in all
> > the cases.
> > > The only case it will work all the time if no wildcards used at all,  which
> > > > > I'd like to stress a "protocol" solution as I do believe that it
> > has to be
> > > > > addressed in
> > > > > the protocol, not outside of it, as not to have intentional "holes"
> > in the
> > > > > protocol.
> > > > >
> > > >protocol is more natural. SCTP for instance already provides this service.
> > >
> > > it is always hot in your home. Instead you will probably first see if
> > you can
> > > All I'm saying is if a protocol (not specifically MEGACO) defines set
> > of rules,

---

From: "Alf Heidermark (EAB)" <[email-masked]>
Date: Mon, 15 Jul 2002 08:30:46 +0200

Hi

Alf

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: den 15 juli 2002 00:31
To: Aleksandr Ryabin
Cc: Christian Groves; [email-masked]
Subject: Re: Segmentation (was Re: [Megaco] Wildcarded Action Reply)

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 15 Jul 2002 23:48:33 -0400

I've been rather maxed out or else pretty well inaccessible for the last few
weeks, but here I am now.  I'm not really convinced that you need an
application-level solution to a transport problem.    SIP has run into the
same difficulty, and are facing the reality that they have to use TCP or
SCTP.  I should note that H.248v2 provides part of an answer by allowing
more selective auditing (thanks to Christian's efforts).

In any event, "requirement" 8 is not a requirement -- it is a technical
proposal.  I also want to make sure one point is well understood: there are
only two versions of the protocol, 1 and 2.  3015corr is version 1 with all
corrections rolled in.  That said, if you really want to meet requirement 7,
it has to be by clever use of existing version 1 protocol mechanisms.  These
mechanisms are defined by the main body of the specification.  You cannot
contradict anything in the main body by what you write in a package.

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Friday, July 12, 2002 11:11 AM
To: Christian Groves; [email-masked]
Subject: Re: Segmentation (was Re: [Megaco] Wildcarded Action Reply)

Hi Christian and folks,

Thanks
         Aleks

then
the
is
in
messages
behaviour
out
what
you
replies.
which
service.

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 16 Jul 2002 12:12:47 -0400

I'm not so much worried about termination audits -- those are easily
segmented through judicious use of partial wildcards in the requests.
However, CONTEXT audits are not so easily segmented, especially since
partial wildcards are not allowed in context IDs.

Consider this:

!/2 [1.2.3.4]:2944 T=5{C=*{AV=Root{AT{}}}}

The response would be:

!/2 [1.2.3.5]:2944
P=5{C=1{AV=Root{}},C=2{AV=Root{}},C=3{AV=Root{}},...,C=4294967295{AV=Root{}}
}

Remember that the context ID space is 32 bits wide, and very large gateways
could have thousands (or more) of calls at any given moment.  This response
is about 1.5K in size at about 100 contexts.  It grows faster as the context
IDs get larger.  

That being said, I, personally, have no problem with saying that this should
be handled via transport.  But, keep in mind that:

1) MGs may choose to support only UDP,
2) MGCs cannot establish TCP/SCTP connections to MGs -- they have to be
established by the MG,
3) we can't remove UDP from v1 and v2.

I believe that if we are going to allow the use of UDP, and we are going to
allow the construction of giant messages, that we should be able to send
those messages.

Here's a couple additional thoughts on requirements for a potential
segmentation solution:

The MG should be able to initiate segmentation on its own, not depend on the
MGC segmenting the request upon receipt of an error.
Not only should segmentation/reassembly errors be detected, the mechanism
should gracefully recover from those errors.
Since this would apply to UDP, the exisiting ALF mechanism should be reused
with as little change as possible.

I am not so attached to having a unified solution for all versions.  Part of
the point of a new version is adding enhancements that were overlooked in
the previous ones, such as individual property audit.  This seems, to me, to
be one of those kinds of enhancements.

Kevin

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, July 16, 2002 10:12 AM
To: Taylor, Tom-PT [CAR:B602:EXCH]; Aleksandr Ryabin; Christian Groves;
[email-masked]

>I was planning to mention the SIP stuff myself, but I didn't since I think
there
>are some different issues between the problem in SIP and H.248 (they are
pretty
>relevant, however, so we don't need to go into those...).

Non-relevant, that is... ;)

Regards.

Christer Holmberg
Ericsson Finland

Christer Holmberg wrote:

> Hi,
>
> I was planning to mention the SIP stuff myself, but I didn't since I think
there
> are some different issues between the problem in SIP and H.248 (they are
pretty
> relevant, however, so we don't need to go into those...).
>
> I also think that for AuditXxx the problem can be solved pretty easy by
> splitting the wildcard into smaller pieces. For wildcarded Subtracts,
however,
> it MAY be more difficult. It really depends on how much the MGC knows
about the
> MG (we should assume it may not know anything), the MG termination naming
> pattern, and how time critical the operation is, etc etc etc.
>
> However, I think the first question we should ask: for how many people
would it
> be a problem if we only had a transport based mechanism? In other words,
is it a
> problem to use some other transport protocols (for specific, or all,
messages)
> than UDP? Again, I don't have anything against having an application based
> segmentation mechanism, but what I'm trying to figure out is how much it's
> really needed :)
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
> Tom-PT Taylor wrote:
>
> > > > [AR] Yes it does indeed, as any package does. Although at the same
time
> > it
> > > > >signalling, more timely responses. It seems to me to have it
outside
> > > > these set of rules (in ideal world) SHELL work all the time.
Applying
> > this
> > > > for MGC and it defines usage of wildcard, but in a real world this
is
> > not

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 18 Jul 2002 01:35:11 -0400

In v1 we deliberately left the segmentation issue for another day.  We
figured it was more important to get implementation experience and see what
was really required.  I can only suggest that if these massive audits are
really required, large v1 gateways will have to support TCP or SCTP: market
pressures will make themselves felt.

-----Original Message-----
From: Boyle, Kevin [NCRTP:3R90:EXCH] 
Sent: Tuesday, July 16, 2002 12:13 PM
To: Christer Holmberg; Taylor, Tom-PT [CAR:B602:EXCH]; Aleksandr Ryabin;
Christian Groves; [email-masked]
Subject: RE: Segmentation (was Re: [Megaco] Wildcarded Action Reply)

Consider this:

The response would be:

!/2 [1.2.3.5]:2944

Kevin

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, July 16, 2002 10:12 AM
To: Taylor, Tom-PT [CAR:B602:EXCH]; Aleksandr Ryabin; Christian Groves;
[email-masked]

there
pretty

Regards.

Christer Holmberg
Ericsson Finland

there
pretty
however,
about the
would it
is it a
messages)
time
outside
Applying
is

---

From: [email-masked]
Date: Fri, 19 Jul 2002 09:19:12 +0530

Aleksandr,
           When the discussion started on the list on the segmentation issue, I
had a look at
  this draft of MGCP that you mention below.

As far as my understanding goes,  the package concept of MGCP gives
 far more flexibility of extending the protocol as compared to MEGACO. While
MEGACO permits
 you to add new events, signals, properties and statistics through packages,
MGCP allows
 you to add any new parameter in the protocol. Thus, if you see the MGCP Bulk
Audit draft, it
 adds a new parameter "BA:". This parameter is at the same level as the "R:" or
Requested
Events (equivalent to the Event Descriptor in MEGACO) parameter. The package
also adds
 new return values for the AuditEndpoint command. In my view, adding new
parameters
 and new return arguments to an API is almost like adding a new command. I don't
think
 the MEGACO protocol definition allows this level of extensibility.

Rgds,

Vikas Bajaj

Aleksandr Ryabin <[email-masked]> on 07/18/2002 08:44:06 PM

To:   Christer Holmberg <[email-masked]>, [email-masked],
      Carl Rutter <[email-masked]>, Tom-PT Taylor
      <[email-masked]>, Kevin Boyle <[email-masked]>,
      "'Christian Groves'" <[email-masked]>
cc:    (bcc: Vikas Bajaj/HSS)

Hi,

BTW It just hit me that MGCP already has a proposed "bulk audits" draft
http://www.ietf.org/internet-drafts/draft-foster-mgcp-bulkaudits-02.txt
I know MGCP is not MEGACO :), but this is just an advocate the idea
of using a package to solve the issue.

Cheers.
         Aleks

At 11:02 AM 7/18/2002, Christer Holmberg wrote:

>Hi,
>
>I don't think we have to define "large" and "small" wildcards. The point
>is that
>when wildcards are used there is a risk that the reply messages may be too
>big for
>UDP. Short and simple :)
>
>I am not even sure audits is the biggest problem (there may eg be bigger
>issues
>with subtracts), but that's also beside the point. Wildcarding and UDP just
>doesn't match (assuming you don't use an application based segmentation
>mechanism,
>that is) - no matter the command :)
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland
>
>
>Aleksandr Ryabin wrote:
>
> > But you will still have problem with wildcard context audits (as Kevin
> noted)
> > as well as when the "smallest" wildcard (e.g. one trunk) still produces too
> > large reply.
> >
> >          Aleks
> >
> > At 06:49 AM 7/18/2002, Carl Rutter wrote:
> > >In addition to what Tom just said,
> > >If not TCP or SCTP
> > >The MGs will send up 533s and the MGCs that are dealing with large
> trunking
> > >etc Gateways
> > >will have to deal with paring their requests down, as currently discussed.
> > >
> > >Carl
> > >----- Original Message -----
> > >From: "Tom-PT Taylor" <[email-masked]>
> > >To: "Kevin Boyle" <[email-masked]>; "'Christer Holmberg'"
> > ><[email-masked]>; "'Aleksandr Ryabin'"
> > ><[email-masked]>; "'Christian Groves'"
> > ><[email-masked]>; <[email-masked]>
> > >Sent: Thursday, July 18, 2002 1:35 AM
> > > > I believe that if we are going to allow the use of UDP, and we are
> going
> > >to
> > > > The MG should be able to initiate segmentation on its own, not
> depend on
> > >the
> > > > I am not so attached to having a unified solution for all
> versions.  Part
> > >of
> > > > the previous ones, such as individual property audit.  This seems,
> to me,
> > >to
> > > > > > I've been rather maxed out or else pretty well inaccessible for the
> > >last
> > > > few
> > > > > > application-level solution to a transport problem.    SIP has
> run into
> > > > the
> > > > > > same difficulty, and are facing the reality that they have to
> use TCP
> > >or
> > > > > > proposal.  I also want to make sure one point is well understood:
> > >there
> > > > are
> > > > > > only two versions of the protocol, 1 and 2.  3015corr is version 1
> > >with
> > > > all
> > > > > > it has to be by clever use of existing version 1 protocol
> mechanisms.
> > > > These
> > > > > > >Segmentation is new functionality, however you try to bend it, it
> > >does
> > > > not
> > > > > > >clarify
> > > > > > >you don't need to implement UDP. The example you gave of
> timestamps
> > >is
> > > > not
> > > > > > the
> > > > > > >code 533) where by the MG can indicate that a response is too
> large
> > >and
> > > > > > >then the
> > > > > > >Let's talk about requirement rather than protocol solution. A
> start
> > >for
> > > > > > some
> > > > > > >requirements would be:
> > > > > > >o Minimise dependencies (maximise transparency) to the Megaco
> state
> > > > machine
> > > > > > > > > > core protocol" I'd like to point out that there are
> numerous
> > > > drafts
> > > > > > out
> > > > > > > > > > there that
> > > > > > > > > > not contradict (e.g. breaks) basic protocol
> functionality, but
> > > > > > rather
> > > > > > > > > > clarifies how
> > > > > > > > >because a draft is written and submitted to the IETF
> doesn't mean
> > > > that
> > > > > > > it is
> > > > > > > > [AR] Any package which has "Procedures" paragraph does
> clarify how
> > > > and
> > > > > > what
> > > > > > > > I do not want to go into debate of "what did you precisely mean
> > >and
> > > > why
> > > > > > you
> > > > > > > > clarifies and "fixes" usage of core protocol in the place
> where it
> > > > has
> > > > > > > a flaw.
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I mean for this specific case, where does the the
> protocol say
> > > > that
> > > > > > > MG has
> > > > > > > > > > to return
> > > > > > > > > > exactly the same reply to two exactly the same transactions
> > >with
> > > > > > only
> > > > > > > > > > difference
> > > > > > > > > > in time sent and transaction ids? Thus MG can possibly
> return
> > > > even
> > > > > > > > > right now
> > > > > > > > > > approach does not invent here anything, but rather
> "controls"
> > >MG
> > > > on
> > > > > > > > > what and
> > > > > > > > >[CHG] You do not need the "split" package for the MGC to
> do this.
> > > > We
> > > > > > > already
> > > > > > > > [AR] As I already suggested, granularity is not going to
> work in
> > >all
> > > > > > > the cases.
> > > > > > > > is not a best solution in some cases, thus we have this
> discussion
> > > > :)
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I'd like to stress a "protocol" solution as I do
> believe that
> > >it
> > > > > > > has to be
> > > > > > > > > > addressed in
> > > > > > > > >[CHG] Why? Shouldn't we look at the benefits of such an
> approach?
> > > > Less
> > > > > > > > Let me rephrase. I have nothing against using of benefits
> outside
> > > > the
> > > > > > > protocol.
> > > > > > > > it is not that easy to "fix" a core protocol limitation, by
> > >seeking
> > > > to
> > > > > > > patch it
> > > > > > > > on outside of a protocol. Sometimes it is easier to switch
> to some
> > > > other
> > > > > > > > it is always hot in your home. Instead you will probably
> first see
> > > > if
> > > > > > > you can
> > > > > > > > All I'm saying is if a protocol (not specifically MEGACO)
> defines
> > > > set
> > > > > > > of rules,

---

From: [email-masked]
Date: Fri, 19 Jul 2002 10:06:58 +0530

Christian,
        I have a small doubt in relation to the proposal below of (almost)
mandating SCTP or TCP.
 Does use of SCTP or TCP permit Hot Swap configuration of the MGC (assuming Hot
Swap
  to mean that MG is transparent to switchover happening at the MGC in the
context of this
 discussion thread) ?

Rgds,

Vikas Bajaj

Christian Groves <[email-masked]> on 07/18/2002 09:17:32 AM

To:   Kevin Boyle <[email-masked]>
cc:   Christer Holmberg <[email-masked]>, Tom-PT Taylor
      <[email-masked]>, Aleksandr Ryabin <[email-masked]>,
      [email-masked] (bcc: Vikas Bajaj/HSS)

G'Day Kevin,

I think what you have is a fair summary. I agree that we can't remove UDP from
v1 or v2. Perhaps in v3 (whenever it comes) we'll remove the requirement that if
you support IP you have to support UDP. I think the first 2 requirements listed
below are probably a good idea. I'm not sure what the effects of your third
requirement are. I assume that if we support UDP we still have to be compliant
to ALF defined in v1 and v2.

Regards, Christian

---

From: [email-masked]
Date: Tue, 23 Jul 2002 09:47:55 +0530

Aleksandr,
            This was my understanding as well. Unless this has been considered
when designing
  the Hot Swap architecture, it will not be possible to move to TCP or SCTP.
However, given that
  for MGCs the protocol has always mandated the support of all transport
protocols, most vendor
 implementations would have taken into account this requirement when
architecting the
 systems.

Rgds,

Vikas Bajaj

Aleksandr Ryabin <[email-masked]> on 07/22/2002 08:40:07 PM

To:   Christian Groves <[email-masked]>, Vikas Bajaj/HSS@HSS,
      [email-masked]
cc:   Kevin Boyle <[email-masked]>, Christer Holmberg
      <[email-masked]>, Tom-PT Taylor
      <[email-masked]>

Hi,

I agree that theoretically it should be no problem. Although while for UDP
it is might be
quite trivial to maintain signalling association since there is no physical
connection and
the most MG will have to do an ARP if hardware (ethernet) address of MGC
changes,
in case of other protocols it might not be trivial to maintain physical
connection
state on MGC (that is transport protocol data). Thus for hot swap systems
which
currently use UDP it might not be trivial to move to other protocols if MEGACO
drops UDP support.

I know this is out of scope for MEGACO, but figured it would be worth saying
to make the protocol more implementation/realization friendly :)

Thanks
         Aleks.

At 02:34 AM 7/22/2002, Christian Groves wrote:
>G'Day Vikas,
>
>I can't see why not, so long as the signalling association is maintained.
>
>Regards, Christian
>
>[email-masked] wrote:
> >
> > Christian,
> going to
> versions.  Part of

---

From: [email-masked]
Date: Tue, 23 Jul 2002 09:47:55 +0530

Aleksandr,

Rgds,

Vikas Bajaj

Hi,

Thanks
         Aleks.