RE: H.248 IP Router Package; Re: Question on Interface Routing ...

 

> -----Original Message-----
> From: Albrecht.Schwarzalcatel-lucent.de 
> [mailto:Albrecht.Schwarzalcatel-lucent.de] 
> Sent: Sunday, March 11, 2007 2:00 AM
> To: Reinaldo Penno
> Cc: megacoietf.org
> Subject: RE: H.248 IP Router Package; Re: [Megaco]
Question 
> on Interface Routing ...
> 
> 
> Reinaldo,
> 
> like to start with your last comments.
> 
> We should recall that an H.248 IP-to-IP MG, - with an
H.248 
> Context with two H.248 IP Terminations (T1, T2; with
Streams 
> S1) -, is firstly behaving as an Back-to-Back IP Host 
> (B2BIH), and not as an IP Router (IPR).
> 

Well, I think this where the disconnect is. Originally a MGW
was like a glotified TDM interconnected where "port A
connect to port B". But when the MGW concept was
brought into the IP world through the Ia interface, this
concept does not translate well and this issue seems
untackled. When I look at this definition, it seems it is
sugesting some kind of "Layer 3 bridging".

It seems to me that _by definition_ the only way to achieve
that in a real world router is to override its routing
table. There are many methods to achieve that, but
nonenthless seems like layering violation.

> Each H.248 Stream endpoint represents basically an
"IP host" 
> function. The Stream endpoints within an H.248 Context
are 
> interconnected due to the "Context Topology".
We got an B2BIH.
> 

I undertand (and kind of like) this concept but it seems to
work well maybe in a workstation with two interface cards.
You know, a very simplistic "router".

> The second aspect is how IP address/ports of the hosts
are 
> assigned via
> H.248 LD & RD. You may see already one gap
concerning the IP 
> SA/SP of the egress flow.
> 
> The B2BIH mode relates to the interconnection of two IP

> (bearer) connection endpoints and correspondingly one
or more 
> media flows (number of H.248 Streams).

Understood. But again, making this
"interconnection" in a router means
interconnecting at several levels:

1 - There is the whole IP addressing interconnection issue
when NAT is in use.
2 - There is the interface interconection issue. T1 is in
interface ip/1/2 and T2 is in interface ip/2/3. 
3 - If I perform dest (or twice) NAT clearly the next-hop
that I get from the routing table might indicate an output
iterface that does not match ip/2/3
4 - And even without NAT the routing table lookup might give
me a egress interface that does not match ip/2/3.

So, how can the context topology be guaranteed? Now, imagine
many (as in tens of thousands) B2BIHs as you put it.

You basically creating an N^2 interconnection mesh inside
the router to guarantee such behavior. Since a router is not
a TDM switch, this is (very) hard to achieve. Of course if
many terminations have ip/1/2 as ingress interface and
ip/2/3 as egress interface, we set up one
"interconnection" for many terminations. But it
remains to be seen how big deployments will look like. 

> 
> The IPR mode has two sub-modes: single H.248 Context
for IP 
> forwarding of
> a)    single IP connection or
> b)    multiple connections.
> 
> This is then related to the address space (not port
space 
> because it's IP forwarding, i.e. layer 3 only) behind
the 
> H.248 Streams/Terminations. This requires specific
handling 
> of the LD/RD, which could be controlled via a new
property.
> 

It seems to me (correct me if I'm wrong) that we are still
missing the interface aspect of the terminations as I
discuessed above.  

Thanks,

Reinaldo

> -Albrecht
> 
> 
>                                                        
      
>                                                        
      
>             
>                       "Reinaldo Penno"       
                
>                                                        
      
>             
>                       <rpennojuniper.         To:      
> <Albrecht.Schwarzalcatel-lucent.de>      
                   
>                   
>                       net>                     cc:  
   
> megacoietf.org                                             
 
>                   
>                                                Subject:
RE: 
> H.248 IP Router Package;  Re: [Megaco] Question on
Interface 
> Routing ...    
>                       28.02.2007 17:53                 
      
>                                                        
      
>             
>                                                        
      
>                                                        
      
>             
> 
> 
> 
> 
> Wow! You followed up in this? I have to say I'm
impressed.
> 
> Inline....
> 
> > -----Original Message-----
> > From: Albrecht.Schwarzalcatel-lucent.de
> > [mailto:Albrecht.Schwarzalcatel-lucent.de]
> > Sent: Wednesday, February 28, 2007 6:19 AM
> > To: Reinaldo Penno
> > Cc: megacoietf.org
> > Subject: H.248 IP Router Package; Re: [Megaco]
Question on 
> Interface 
> > Routing ...
> >
> >
> > Reinaldo,
> >
> > independent of your question concerning the
specific TerminationID 
> > syntax in ES 283 018, we did look at the IP router
capability:
> >
> > > The scenario is a BGF with many input and
output interfaces.
> >
> > >      +----+
> > > Ifa -|    |-ifx
> > > Ifb -| RT |-ify   RT means routing table
> > > Ibc -|    |-ifz
> > >      +----+
> >
> > The starting point is an IP-to-IP H.248 Context,
and how 
> the "Context" 
> > must behave in order to realize an "IP
router"
> > function. The requirements for such a functions
could be firstly 
> > limited to the "IP forwarding process"
> > itself (see e.g. requirements set given by RFC
1812, § 5.2).
> >
> > When you try to realize such a packet forwarding
process, 
> it's fairly 
> > obvious that it's not possible to configure the
two IP 
> > Terminations/Streams via their LDs/RDs and with
existing H.248 
> > elements for such a behaviour.
> 
> Agreed.
> 
> > On the other side, introducing e.g.  at least two

> properties (an "IP 
> > forwarding" and an "IP FIB"
property), then you may achieve a 
> > behaviour very close to RFC 1812, § 5.2 IMHO.
> >
> > ...<snip> (no more details here about such
an IP router package 
> > because still in discussion ...)
> 
> Is there a draft about it?
> 
> >
> > -Albrecht
> >
> > PS
> > Is there a requirement for such a function in an
H.248 MG?
> > On the first glance definitely not, because this
is more a 
> > "call/session-independent function".
> 
> 
> Well, I had many discussions about this internally and

> externally. Reading the current specs I told these
people 
> that context/terminations should be independent of
routing, 
> but many (external) people disagree with me. My stance
is 
> that is fine to disagree as long as there is something
in 
> place to tell me how a packet should be routed within a

> context (and its ingress/egress terminations).
> 
> It could be:
> 
> 1. Forwarding/routing takes care of it (this would be
the 
> current behavior) based on the existing specs.
> 2. Some new package that tells me how to make sure
packets 
> ingress and egress through the desired interfaces
(which at 
> some layer relate to the terminations like ip/1/32).
> 
> My problem today is that some people want 1 and others
2. The 
> people that want 2 believe that a context by definition

> create some sort of session dependent routing. And
since the 
> MGC cannot instantiate this (because it does see data 
> packets), it tells the MGW to do it. And creating a
context 
> is a implicit way of doing it.
> 
> >From my perspective I just would like this stuff to
be well 
> documented 
> >and
> specified.
> 
> > But we may already support session-independent
functions with
> > H.248 ...
> >
> > Or, an H.248 AGW/TGW or BGW may be interconnected
to an IP 
> edge router 
> > (ER), thus the MG is a front-end element of the
ER. But on 
> the other 
> > side you may also embedd the ER function in the MG
... and 
> you may use 
> > an H.248 Context for the ER traffic ... etc etc
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >                       Albrecht
> >
> >
> >                       SCHWARZ/DE/ALCAT        
To:
> > "Reinaldo Penno" <rpennojuniper.net>
> >
> >                       ELALCATEL               cc:
> > megacoietf.org
> >
> >                                               
Subject: Re:
> > [Megaco] Question on Interface Routing in relation
to H.248 Profile
> >                       16.10.2006 15:39        
for
> > controlling Border Gateway Functions (BGF) (ETSI
ES 283 018)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Reinaldo,
> >
> > 1st H.248 vs IP RIB/FIB
> >    There aren't any H.248 capabilities defined so
far, allowing the
> >    modification of IP RIB/FIB data bases. Thus,
H.248 is
> > entirely decoupled
> >    from IP routing protocols.
> >
> > 2nd TerminationID
> >    Don't over-interprete this TerminatinationID
structure. 
> The defined
> >    naming convention by ES 283 018 is rather
specific because
> > besides the
> >    basic "identification" function, the
syntax is also a)
> > overloaded with
> >    other functions (a1 -> usage of
<group>; a2 -> usage of
> > <interface>);
> >    and b) hierarchical (-> benefit in case of
wildcarding).
> >
> >    The prime purpose behind (a2) is "IP
address realm"
> > indication. Please
> >    note that the ipdc package (H.248.41) was not
yet
> > available when ES 283
> >    018 was defined.
> >    So, the term "interface" could
mislead if interpreted as
> > "IP interface"
> >    (but this isn't the definition by Table 4/ES
283 018).
> >
> > - Albrecht
> >
> >
> >
> >
> >                       "Reinaldo Penno"
> >
> >                       <rpennojuniper. 
       To:
> > <megacoietf.org>
> >
> >                       net>                    
cc:
> >
> >                                               
Subject:
> > [Megaco] Question
> > on Interface Routing in relation to H.248 Profile 
   for
> >                       14.10.2006 09:00        
controlling
> > Border Gateway
> > Functions (BGF) (ETSI ES 283 018)
> >
> >
> >
> >
> >
> > In the specification above (or TS 102 333 for that
matter)
> > there is a proposal for the termination ID.
> >
> > "5.6.1.1.1 Overview and prose specification
The Termination
> > ID structure shall follow the guidelines of H.248
and shall
> > be based on four fields:
> > *
"ip/<group>/<interface>/<id>".&q
uot;
> >
> > I would like to understand what
"interface" means in this
> > context when related to routing.
> >
> > The scenario is a BGF with many input and output
interfaces.
> >
> >      +----+
> > Ifa -|    |-ifx
> > Ifb -| RT |-ify   RT means routing table
> > Ibc -|    |-ifz
> >      +----+
> >
> > Packets come from one of the input interfaces
(left), a
> > routing lookup is done, and exit through one of
the output
> > interfaces (right).
> >
> > Given the termination ID ip/1/ifx/200 and a gate
with source
> > IP a.b.c.d and destination IP e.f.g.h associated
with it,
> > which actions should be done?
> >
> > A) One should attach the termination to interface
Ifx and if
> > packets go through that interface (and
termination) any gate
> > actions are applied.
> >
> > B) One should override the routing table in order
to make
> > sure that packets from source a.b.c.d and
destination e.f.g.h
> > go through Ifx.
> >
> >
> > The two approaches are quite different:
> >
> > The first provides a clean separation of Gate
Control and
> > routing. You configure routing to make sure the
packets you
> > are interested on go through the proper interface
(and
> > consequently hit the termination) when
egress/ingress the router.
> >
> > The second approach means an overide of the
routing table by
> > the H.248 process. Although possible this
represents a
> > protocol layer violation and it makes me worried
about
> > unforseen interaction between routing protocols
and H.248
> > driven routing table changes.
> >
> > What would be the correct interpretation?
> >
> > Thanks,
> >
> > Reinaldo
> >
> > _______________________________________________
> > Megaco mailing list
> > Megacoietf.org
> > https:/
/www1.ietf.org/mailman/listinfo/megaco
> >
> >
> >
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > Megacoietf.org
> > https:/
/www1.ietf.org/mailman/listinfo/megaco
> >
> >
> >
> >
> 
> _______________________________________________
> Megaco mailing list
> Megacoietf.org
> https:/
/www1.ietf.org/mailman/listinfo/megaco
> 
> 
> 
> 

_______________________________________________
Megaco mailing list
Megacoietf.org
https:/
/www1.ietf.org/mailman/listinfo/megaco

Reinaldo,

1)
starting point is the H.248.1 connection and context model,
don't be so
minded from an service/edge/core router perspective.
There are two terminations types, PHY and EPH terminations.
Relevant here
is the principle how H.248 Streams/Terminations got there
network address
(or connection endpoint address).
H.248 Contexts with two IP terminations is nothing new, -
the Ia/1 profile
is not the first application.

The general context for packet-switched networks for 2PTY
communication is
EPH-to-EPH. We got applications already before TISPAN R1 in
mobile (see
3GPP R4) and fixed networks. I cannot see nothing new with
IP-to-IP
Contexts. This was already part of the H.248.1 V1 design
since 6, 7 years.
(Guess this is one majore difference to MGCP, which
primarily supports only
PHY-to-IP connection models.)

2)
Ia TerminationID naming scheme and term
"interface":
I may guess that this term might be confusing when having
only
logical/physical IP interfaces in mind.
But the ES 283 018 term is more general, could be a
"generic interface" or
even just a non-IP interface, like a layer 2 interface.
Please note that this TerminationID field is used to
"emulate" the H.248.41
functionality ("IP realm indication"), whereas the
IP connection endpoint
identification is given by LD/RD IP address information, IP
SA/SP used for
egress traffic and the TermID.
[So, the ES 283 018 TermID field "interface" is
typically related to an "IP
address range", but not a single address.]


Don't think that the H.248 concept is broken with the Ia
Profile, it's
rather vice versa the the H.248 connection model did
consider from the
initial design EPH-to-EPH connections.

Perhaps another aspect is that
the B2BIH function is related to session-dependent control
(like in TISPAN
RACS, wherease
the IPR is basically session-independent (e.g. like for
RACS).

-Albrecht





                                                            
                                                            
              
                      "Reinaldo Penno"            
                                                            
                        
                      <rpennojuniper.         To:     
<Albrecht.Schwarzalcatel-lucent.de>                     
                      
                      net>                     cc:     
megacoietf.org                                             
                   
                                               Subject: RE:
H.248 IP Router Package;  Re: [Megaco] Question on Interface
Routing ...    
                      11.03.2007 11:42                      
                                                            
              
                                                            
                                                            
              






> -----Original Message-----
> From: Albrecht.Schwarzalcatel-lucent.de
> [mailto:Albrecht.Schwarzalcatel-lucent.de]
> Sent: Sunday, March 11, 2007 2:00 AM
> To: Reinaldo Penno
> Cc: megacoietf.org
> Subject: RE: H.248 IP Router Package; Re: [Megaco]
Question
> on Interface Routing ...
>
>
> Reinaldo,
>
> like to start with your last comments.
>
> We should recall that an H.248 IP-to-IP MG, - with an
H.248
> Context with two H.248 IP Terminations (T1, T2; with
Streams
> S1) -, is firstly behaving as an Back-to-Back IP Host
> (B2BIH), and not as an IP Router (IPR).
>

Well, I think this where the disconnect is. Originally a MGW
was like a
glotified TDM interconnected where "port A connect to
port B". But when the
MGW concept was brought into the IP world through the Ia
interface, this
concept does not translate well and this issue seems
untackled. When I look
at this definition, it seems it is sugesting some kind of
"Layer 3
bridging".

It seems to me that _by definition_ the only way to achieve
that in a real
world router is to override its routing table. There are
many methods to
achieve that, but nonenthless seems like layering
violation.

> Each H.248 Stream endpoint represents basically an
"IP host"
> function. The Stream endpoints within an H.248 Context
are
> interconnected due to the "Context Topology".
We got an B2BIH.
>

I undertand (and kind of like) this concept but it seems to
work well maybe
in a workstation with two interface cards. You know, a very
simplistic
"router".

> The second aspect is how IP address/ports of the hosts
are
> assigned via
> H.248 LD & RD. You may see already one gap
concerning the IP
> SA/SP of the egress flow.
>
> The B2BIH mode relates to the interconnection of two
IP
> (bearer) connection endpoints and correspondingly one
or more
> media flows (number of H.248 Streams).

Understood. But again, making this
"interconnection" in a router means
interconnecting at several levels:

1 - There is the whole IP addressing interconnection issue
when NAT is in
use.
2 - There is the interface interconection issue. T1 is in
interface ip/1/2
and T2 is in interface ip/2/3.
3 - If I perform dest (or twice) NAT clearly the next-hop
that I get from
the routing table might indicate an output iterface that
does not match
ip/2/3
4 - And even without NAT the routing table lookup might give
me a egress
interface that does not match ip/2/3.

So, how can the context topology be guaranteed? Now, imagine
many (as in
tens of thousands) B2BIHs as you put it.

You basically creating an N^2 interconnection mesh inside
the router to
guarantee such behavior. Since a router is not a TDM switch,
this is (very)
hard to achieve. Of course if many terminations have ip/1/2
as ingress
interface and ip/2/3 as egress interface, we set up one
"interconnection"
for many terminations. But it remains to be seen how big
deployments will
look like.

>
> The IPR mode has two sub-modes: single H.248 Context
for IP
> forwarding of
> a)    single IP connection or
> b)    multiple connections.
>
> This is then related to the address space (not port
space
> because it's IP forwarding, i.e. layer 3 only) behind
the
> H.248 Streams/Terminations. This requires specific
handling
> of the LD/RD, which could be controlled via a new
property.
>

It seems to me (correct me if I'm wrong) that we are still
missing the
interface aspect of the terminations as I discuessed above.

Thanks,

Reinaldo

> -Albrecht
>
>
>
>
>
>                       "Reinaldo Penno"
>
>
>                       <rpennojuniper.         To:
> <Albrecht.Schwarzalcatel-lucent.de>
>
>                       net>                     cc:
> megacoietf.org
>
>                                                Subject:
RE:
> H.248 IP Router Package;  Re: [Megaco] Question on
Interface
> Routing ...
>                       28.02.2007 17:53
>
>
>
>
>
>
>
>
>
> Wow! You followed up in this? I have to say I'm
impressed.
>
> Inline....
>
> > -----Original Message-----
> > From: Albrecht.Schwarzalcatel-lucent.de
> > [mailto:Albrecht.Schwarzalcatel-lucent.de]
> > Sent: Wednesday, February 28, 2007 6:19 AM
> > To: Reinaldo Penno
> > Cc: megacoietf.org
> > Subject: H.248 IP Router Package; Re: [Megaco]
Question on
> Interface
> > Routing ...
> >
> >
> > Reinaldo,
> >
> > independent of your question concerning the
specific TerminationID
> > syntax in ES 283 018, we did look at the IP router
capability:
> >
> > > The scenario is a BGF with many input and
output interfaces.
> >
> > >      +----+
> > > Ifa -|    |-ifx
> > > Ifb -| RT |-ify   RT means routing table
> > > Ibc -|    |-ifz
> > >      +----+
> >
> > The starting point is an IP-to-IP H.248 Context,
and how
> the "Context"
> > must behave in order to realize an "IP
router"
> > function. The requirements for such a functions
could be firstly
> > limited to the "IP forwarding process"
> > itself (see e.g. requirements set given by RFC
1812, § 5.2).
> >
> > When you try to realize such a packet forwarding
process,
> it's fairly
> > obvious that it's not possible to configure the
two IP
> > Terminations/Streams via their LDs/RDs and with
existing H.248
> > elements for such a behaviour.
>
> Agreed.
>
> > On the other side, introducing e.g.  at least two
> properties (an "IP
> > forwarding" and an "IP FIB"
property), then you may achieve a
> > behaviour very close to RFC 1812, § 5.2 IMHO.
> >
> > ...<snip> (no more details here about such
an IP router package
> > because still in discussion ...)
>
> Is there a draft about it?
>
> >
> > -Albrecht
> >
> > PS
> > Is there a requirement for such a function in an
H.248 MG?
> > On the first glance definitely not, because this
is more a
> > "call/session-independent function".
>
>
> Well, I had many discussions about this internally and
> externally. Reading the current specs I told these
people
> that context/terminations should be independent of
routing,
> but many (external) people disagree with me. My stance
is
> that is fine to disagree as long as there is something
in
> place to tell me how a packet should be routed within
a
> context (and its ingress/egress terminations).
>
> It could be:
>
> 1. Forwarding/routing takes care of it (this would be
the
> current behavior) based on the existing specs.
> 2. Some new package that tells me how to make sure
packets
> ingress and egress through the desired interfaces
(which at
> some layer relate to the terminations like ip/1/32).
>
> My problem today is that some people want 1 and others
2. The
> people that want 2 believe that a context by
definition
> create some sort of session dependent routing. And
since the
> MGC cannot instantiate this (because it does see data
> packets), it tells the MGW to do it. And creating a
context
> is a implicit way of doing it.
>
> >From my perspective I just would like this stuff to
be well
> documented
> >and
> specified.
>
> > But we may already support session-independent
functions with
> > H.248 ...
> >
> > Or, an H.248 AGW/TGW or BGW may be interconnected
to an IP
> edge router
> > (ER), thus the MG is a front-end element of the
ER. But on
> the other
> > side you may also embedd the ER function in the MG
... and
> you may use
> > an H.248 Context for the ER traffic ... etc etc
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >                       Albrecht
> >
> >
> >                       SCHWARZ/DE/ALCAT        
To:
> > "Reinaldo Penno" <rpennojuniper.net>
> >
> >                       ELALCATEL               cc:
> > megacoietf.org
> >
> >                                               
Subject: Re:
> > [Megaco] Question on Interface Routing in relation
to H.248 Profile
> >                       16.10.2006 15:39        
for
> > controlling Border Gateway Functions (BGF) (ETSI
ES 283 018)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Reinaldo,
> >
> > 1st H.248 vs IP RIB/FIB
> >    There aren't any H.248 capabilities defined so
far, allowing the
> >    modification of IP RIB/FIB data bases. Thus,
H.248 is
> > entirely decoupled
> >    from IP routing protocols.
> >
> > 2nd TerminationID
> >    Don't over-interprete this TerminatinationID
structure.
> The defined
> >    naming convention by ES 283 018 is rather
specific because
> > besides the
> >    basic "identification" function, the
syntax is also a)
> > overloaded with
> >    other functions (a1 -> usage of
<group>; a2 -> usage of
> > <interface>);
> >    and b) hierarchical (-> benefit in case of
wildcarding).
> >
> >    The prime purpose behind (a2) is "IP
address realm"
> > indication. Please
> >    note that the ipdc package (H.248.41) was not
yet
> > available when ES 283
> >    018 was defined.
> >    So, the term "interface" could
mislead if interpreted as
> > "IP interface"
> >    (but this isn't the definition by Table 4/ES
283 018).
> >
> > - Albrecht
> >
> >
> >
> >
> >                       "Reinaldo Penno"
> >
> >                       <rpennojuniper. 
       To:
> > <megacoietf.org>
> >
> >                       net>                    
cc:
> >
> >                                               
Subject:
> > [Megaco] Question
> > on Interface Routing in relation to H.248 Profile 
   for
> >                       14.10.2006 09:00        
controlling
> > Border Gateway
> > Functions (BGF) (ETSI ES 283 018)
> >
> >
> >
> >
> >
> > In the specification above (or TS 102 333 for that
matter)
> > there is a proposal for the termination ID.
> >
> > "5.6.1.1.1 Overview and prose specification
The Termination
> > ID structure shall follow the guidelines of H.248
and shall
> > be based on four fields:
> > *
"ip/<group>/<interface>/<id>".&q
uot;
> >
> > I would like to understand what
"interface" means in this
> > context when related to routing.
> >
> > The scenario is a BGF with many input and output
interfaces.
> >
> >      +----+
> > Ifa -|    |-ifx
> > Ifb -| RT |-ify   RT means routing table
> > Ibc -|    |-ifz
> >      +----+
> >
> > Packets come from one of the input interfaces
(left), a
> > routing lookup is done, and exit through one of
the output
> > interfaces (right).
> >
> > Given the termination ID ip/1/ifx/200 and a gate
with source
> > IP a.b.c.d and destination IP e.f.g.h associated
with it,
> > which actions should be done?
> >
> > A) One should attach the termination to interface
Ifx and if
> > packets go through that interface (and
termination) any gate
> > actions are applied.
> >
> > B) One should override the routing table in order
to make
> > sure that packets from source a.b.c.d and
destination e.f.g.h
> > go through Ifx.
> >
> >
> > The two approaches are quite different:
> >
> > The first provides a clean separation of Gate
Control and
> > routing. You configure routing to make sure the
packets you
> > are interested on go through the proper interface
(and
> > consequently hit the termination) when
egress/ingress the router.
> >
> > The second approach means an overide of the
routing table by
> > the H.248 process. Although possible this
represents a
> > protocol layer violation and it makes me worried
about
> > unforseen interaction between routing protocols
and H.248
> > driven routing table changes.
> >
> > What would be the correct interpretation?
> >
> > Thanks,
> >
> > Reinaldo
> >
> > _______________________________________________
> > Megaco mailing list
> > Megacoietf.org
> > https:/
/www1.ietf.org/mailman/listinfo/megaco
> >
> >
> >
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > Megacoietf.org
> > https:/
/www1.ietf.org/mailman/listinfo/megaco
> >
> >
> >
> >
>
> _______________________________________________
> Megaco mailing list
> Megacoietf.org
> https:/
/www1.ietf.org/mailman/listinfo/megaco
>
>
>
>

_______________________________________________
Megaco mailing list
Megacoietf.org
https:/
/www1.ietf.org/mailman/listinfo/megaco





_______________________________________________
Megaco mailing list
Megacoietf.org
https:/
/www1.ietf.org/mailman/listinfo/megaco