Subject: RE: H.248 IP Router Package; Re: [Megaco] Question on Interface Routing ...

From: [email-masked]
Date: Sun, 11 Mar 2007 10:59:50 +0100

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).

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.

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).

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.

-Albrecht

                      "Reinaldo Penno"                                                                                                  
                      <rpenno@juniper.         To:      <[email-masked]>                                            
                      net>                     cc:      [email-masked]                                                                 
                                               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: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, February 28, 2007 6:19 AM
> To: Reinaldo Penno
> Cc: [email-masked]
> 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" <[email-masked]>
>
>                       EL@ALCATEL               cc:
> [email-masked]
>
>                                                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"
>
>                       <rpenno@juniper.         To:
> <[email-masked]>
>
>                       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>"."
>
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>

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

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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Sun, 11 Mar 2007 06:42:20 -0400

> Sent: Sunday, March 11, 2007 2:00 AM
> To: Reinaldo Penno
> Cc: [email-masked]
> 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".

> 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. 

> 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"                        
>                                                               
>             
>                       <rpenno@juniper.         To:      
> <[email-masked]>                          
>                   
>                       net>                     cc:      
> [email-masked]                                               
>                   
>                                                Subject: RE: 
> H.248 IP Router Package;  Re: [Megaco] Question on Interface 
> Routing ...    
>                       28.02.2007 17:53                        
>                                                               
>             
>                                                               
>                                                               
>             
> 
> 
> 
> 
> Interface 
> > Routing ...
> > independent of your question concerning the specific TerminationID 
> > syntax in ES 283 018, we did look at the IP router capability:
> >
> > 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"
> 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 ...)
> 
> 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 
> >From my perspective I just would like this stuff to be well 
> documented 
> >and
> specified.
> 
> 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:
> > [Megaco] Question on Interface Routing in relation to H.248 Profile
> >                       16.10.2006 15:39         for

---

From: [email-masked]
Date: Sun, 11 Mar 2007 17:13:42 +0100

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"                                                                                                  
                      11.03.2007 11:42                                                                                                  

> (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.

> 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".

> 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.

> 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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Sun, 11 Mar 2007 16:33:53 -0400

Okay,

I guess I will wait for the document and some examples so we can continue our discussion.

Thanks,

Reinaldo 

> Sent: Sunday, March 11, 2007 9:14 AM
> To: Reinaldo Penno
> Cc: [email-masked]
> 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)
> 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.
> 
> 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"                        
>                                                               
>             
>                       <rpenno@juniper.         To:      
> > 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
> 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.
> 
> 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".
> 
> > H.248 LD & RD. You may see already one gap concerning the 
> IP SA/SP of 
> > the egress flow.
> >
> > (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:
> 
> 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
> 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"
> >
> >
> >                       <rpenno@juniper.         To:
> > H.248 IP Router Package;  Re: [Megaco] Question on 
> Interface Routing 
> > ...
> >                       28.02.2007 17:53
> >
> >
> >
> >
> >
> >
> >
> >
> >
> TerminationID 
> > 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.
> 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.
> >
> > >    modification of IP RIB/FIB data bases. Thus, H.248 is entirely 
> > > decoupled
> overloaded 
> > > with
> available when 
> > > ES 283
> > >    So, the term "interface" could mislead if interpreted as "IP 
> > > interface"
> > > 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:
> > > I would like to understand what "interface" means in this context 
> > > when related to routing.
> > >
> > > 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.
> > >
> sure that 
> > > packets from source a.b.c.d and destination e.f.g.h go 
> through Ifx.
> > >
> > >
> 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.
> > >

---

From: "Reinaldo Penno" <[email-masked]>
Date: Sun, 25 Mar 2007 21:16:13 -0400

Hello Folks,

I tried my best reading the specs but I still have some doubts about
saf/sam in the context of the gate management protocol

Let's suppose an ADD message installs the the following gate&filter [*,
*, UDP, 10.10.10.1, 5060].

If a modify message is received with saf = ON and sam = 20.20.20/24 I
understand that the gate filter will change to [20.20.20/24, *, UDP,
10.10.10.1, 5060].

If another modify message comes and turns saf = OFF, then the gate
reverts back to what it was [*, *, UDP, 10.10.10.1, 5060]. Am I okay up
to this point?

Now, let's suppose the original ADD message installs a full specified
gate [20.20.20.1, 10000, UDP, 10.10.10.1, 5060]. Then a modify message
is received with saf = ON and sam = 20.20.20/24.

My understanding is that sam will _override_ the current source IP in
the gate filter and we will have [20.20.20/24, 10000, UDP, 10.10.10.1,
5060] as the filter. Another possible interpretation is that sam is a
pre/post-filter, i.e., we match against sam and then againt original
gate filter which remains in place. This is my first question.

My second question is what happens is we receive a modify message with
saf = OFF. Does the gate reverts to its original form [20.20.20.1,
10000, UDP, 10.10.10.1, 5060]? Or does it reverts to [*, 10000, UDP,
10.10.10.1, 5060], i.e., source IP "any"?

Thanks,

Reinaldo