Subject: RE: Ephemeral Termination

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 20 Jun 2001 08:43:01 -0400

No, you don't need the ephemeral for a "hairpin" connection.
I don't understand why you would create the ephemeral before you
know the terminating MG.  You might create the context with the
originating termination, but when you determine the terminating
MG is the same you Add the other termination, and if you
determine that it is in another MG then you Add the ephemeral.

A basic call with a hairpin is two physicals in the context.

Brian

> -----Original Message-----
> From: PSK Chakravarthi [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 3:08 AM
> To: [email-masked]
> Subject: Ephemeral Termination
> 
> 
> I have got the following doubt.
> If the originating and terminating termination IDs are on the 
> same gateway and
> gateway supports two TDM terminations in a context, is it 
> required to craete a
> ephenmeral termination for this call?
> 
> Message flow between MGC and MG:
> 
> 1. MGC send ADD command to originating MG
>     a) Choose a context ID
>     b) Add a TDM termination
>     c) Choose a Ephemeral termination
>     d) Reserve Local Descriptor
>     e) set MODE to Receive only.
> 
> 2. MGC now finds that call is terminating on the same MG.  
> Also MGC knows that
> MG is capable of adding two TDMs to the same context.  At 
> this point what should
> be the command to the MG?
> Is it required to SUBTRACT the ephemeral termination and send 
> ADD for adding new
> TDM to the same context? or
> Simply sending ADD for new TDM to the same context is sufficient?
> 
> thanks & regards
> Chak
> 
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 21 Jun 2001 10:56:23 -0400

I'm having trouble following your logic.

This seems to be a trunk GW/ISUP issue, so we don't have to
deal with off hook/DTMF issues, right?

In the case of hairpin, you need two commands:
1) An add to put the originating termination in the context
2) An add to put the terminating termination in the context.
They cannot be in the same transaction if you have not completed
digit analysis before you do 1.  

In the case of a normal connection between two MGs you need
4 total commands:
1) The Add of the physical in the originating MG
2) The Add of the ephemeral in the originating MG
3) The Add of the physical in the terminating MG
4) The Add of the ephemeral in the terminating MG

You can do 1 before you do digit analysis.  You have to
do 3 and 4 after digit analysis, but they can be in the
same transaction.  If you do 2 before you do digit analysis,
you would not have the correct remote SDP, and therefore you would 
need to send a Modify after digit analysis. If you do it
after you do digit analysis, then you only have the 4
commands.  Before digit analysis, the MGC sends 1.
After digit analysis the MGC sends two transactions 
in two messages; one to the originating MG (message 2 containing
correct local and remote SDP) and one to the terminating MG 
(with messages 3 and 4 including all the SDP).  

In most cases, I suspect it would actually be more efficient to
send message 1 after digit analysis, because then the originating
MG has one less transaction to process, but the same number of
commands.  The call setup difference between the originating MG
doing one add before digit analysis and another after vs doing
both after won't matter enough to be measurable I think, but the 
difference in processing of half the number of messages will be substantial.

I see no way to have the Add of the ephemeral before
digit analysis improve call setup time.  It seems to only create
extra work for the originating MG.

Brian

> Sent: Thursday, June 21, 2001 10:10 AM
> To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson'
> Cc: [email-masked]
> Subject: Re: Ephemeral Termination
> 
> 
> The reason for creating Ephemeral and reserving SDP before knowing the
> termination is to reduce the call setup time.
> 
> Following is the MGC processing.
> 
> 1. Soon after receiving IAM send ADD command to the originating MG for
>     a)Creating Ephemeral
>     b)Reserving SDP for Local
>     c)Simultaneously start digit analysis
> After finding termination
> (By this time ADD response would have been received, if not 
> MGC need to wait for
> ADD response)
> If terminating trunk belongs to the same MG
>    a) send ADD command to add the second termination to the 
> same context.
>        This ADD command will have empty Local descriptor to 
> release resources
> previously allocated.
>        Note that ephemeral is not SUBTRACTED.  Also MODIFY to 
> originating MG is
> not required as    MG is going to make only hairpin connection.
> If the terminating MG is not same as originating MG
> Send ADD command to terminating MG
>    a) Creating Ephemeral
>    b) Reserving SDP for Local
>    c) Setting SDP remote as Local returned by the originating MG.
> After receiving the ADD response from terminating MG
> Send MODIFY to originating MG for setting remote Descriptor.
> 
> If you send ADD command to the originating MG only after 
> knowing the terminator,
> MGC had completed processing of the call but now it need to 
> wait for sending
> three commands
> (ADD to originating MG, ADD to terminating MG and MODIFY to 
> originating MG) and
> their responses.
> 
> Take the case of trunking gateway, where the number of calls 
> originating on a MG
> and terminating on the same MG are much less than calls originated and
> terminated on two different MGs.
> 
> thanks & regards
> Chak
> 
> ----- Original Message -----
> From: "Rosen, Brian" <[email-masked]>
> To: "'PSK Chakravarthi'" <[email-masked]>; 
> "'Madhu Babu
> Brahmanapally'" <[email-masked]>; "'Terry L Anderson'" 
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, June 21, 2001 7:21 PM
> Subject: RE: Ephemeral Termination
> 
> 
> > There is no way this will reduce call setup time.
> > Since you do not have the destination information, you
> > will have to MODIFY the ephemeral when you do.  The processing
> > time for the Modify won't be substantially more than doing
> > an Add at that point, and there is no difference to the actual
> > operation of the gateway.
> >
> > Brian
> >
> > > Sent: Thursday, June 21, 2001 1:43 AM
> > > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson'
> > > Cc: [email-masked]
> > > Subject: Re: Ephemeral Termination
> > >
> > >
> > > The reason for creating Ephemeral and reserving SDP 
> before knowing the
> > > termination is
> > > to reduce the call setup time.
> > >
> > > thanks & regards
> > > Chak
> > > ----- Original Message -----
> > > From: "Rosen, Brian" <[email-masked]>
> > > To: "'Madhu Babu Brahmanapally'" <[email-masked]>;
> > > "'Terry L Anderson'"
> > > <[email-masked]>; "'PSK Chakravarthi'"
> > > <[email-masked]>
> > > Cc: <[email-masked]>
> > > Sent: Wednesday, June 20, 2001 9:07 PM
> > > Subject: RE: Ephemeral Termination
> > >
> > >
> > > > I'm not at all sure what "resources" you can reserve before you
> > > > know the destination:
> > > >
> > > > For an IP network, you can reserve a UDP port I 
> suppose, but until
> > > > you negotiate the SDP, you can't reserve bandwidth.  You can't
> > > > make any QoS reservation for the same reason.
> > > >
> > > > It's worse on an ATM network.
> > > >
> > > > I think there is nothing to be gained by #1
> > > >
> > > > Brian
> > > >
> > > > > From: Madhu Babu Brahmanapally [mailto:[email-masked]]
> > > > > Sent: Wednesday, June 20, 2001 11:28 AM
> > > > > To: 'Terry L Anderson'; 'PSK Chakravarthi'
> > > > > Cc: [email-masked]
> > > > > Subject: RE: Ephemeral Termination
> > > > >
> > > > >
> > > > > Hi All,
> > > > > The creation of ephemeral termination can be done either
> > > after digit
> > > > > analysis or before it. Each has its own advantages and
> > > disadvantages.
> > > > >
> > > > > 1) If Ephemeral termination is created before digit analysis,
> > > > > situation may
> > > > > occur where the destination user/termination is connected to
> > > > > the same MG and
> > > > > there is no need to create an ephemeral termination (as PSK
> > > > > mentioned). But
> > > > > this has the advantage that the call wont be dropped due
> > > to lack of
> > > > > resource, as ephemeral resources are pre-reserved at the MG.
> > > > > (in case Add
> > > > > fails later to add ephemeral termination).
> > > > >
> > > > > 2) If Ephemeral termination is created after digit analysis,
> > > > > it takes care
> > > > > of all situation where destination user may/may not connected
> > > > > to the same
> > > > > MG. But when Ephemeral termination is added later, there is no
> > > > > pre-reservation of the ephemeral resources at the 
> origination MG.
> > > > >
> > > > > In case of 1) if the call doesn't mature, reserving the
> > > > > resources doesn't
> > > > > gain anything. Consideration that the destination user on the
> > > > > same MG is
> > > > > less probable, Method 2 IMO will be a better choice.
> > > > >
> > > > > Regards
> > > > > Madhubabu
> > > > >
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]]On Behalf Of Terry
> > > > > L Anderson
> > > > > Sent: Wednesday, June 20, 2001 11:01 AM
> > > > > To: PSK Chakravarthi
> > > > > Cc: [email-masked]
> > > > > Subject: Re: Ephemeral Termination
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > PSK Chakravarthi wrote:
> > > > >
> > > > > > If the originating and terminating termination IDs are on
> > > > > the same gateway
> > > > > and
> > > > > required to
> > > > > craete a
> > > > > Also MGC knows
> > > > > that
> > > > > this point what
> > > > > should
> > > > > > Is it required to SUBTRACT the ephemeral termination and
> > > > > send ADD for
> > > > > adding new
> > > > > It would be better if MGC "finds" that the call is terminated
> > > > > on the same MG
> > > > > before
> > > > > sending the ADD, in step 1c, but if since step c (which you
> > > > > call "Choose a
> > > > > Ephemeral
> > > > > termination) is an Add with wildcard, MGC must certainly
> > > > > Subtract it if it
> > > > > chooses
> > > > > later not to use it.  The Subtract deletes the ephemeral
> > > > > termination and
> > > > > releases
> > > > > its resources.
> > > > >
> > > > > > thanks & regards
> > > > > > Chak
> > > > >
> > > > > --
> > > > > ------------------------------------------------------------
> > > > > Terry L Anderson              mailto:[email-masked]
> > > > > Tel:908.582.7013   Fax:908.582.6729
> > > > > Lucent Technologies/INS/Voice Over IP Access Networks
> > > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> > > > > http://its.lucent.com/~tla (Lucent internal)
> > http://www.gti.net/tla
> > > >
> > > >
> > >
> >
>

---

From: "Sean Leahy" <[email-masked]>
Date: Fri, 22 Jun 2001 09:09:00 +0100

Brian,
     Just a question.

     There may be cases where Megaco is being used solely for bearer control and
the call control/digit analysis is conducted at a layer above the Megaco
protocol. In these circumstances, it is also possible that ephemerals are added
and modified by command from the MGC when the bearer connection is actually
between two physical terminations on the same Media Gateway. Is it altogether
impossible for a Media Gateway to optimise such a hair-pin connection whilst
maintaining the same model to the MGC ?

     Sean Leahy
     Marconi

CN=Brian Rosen/OU=MAIN/O=MC1@MSEXCH on 21/06/2001 15:56:23

                                                              

 To:       "'PSK Chakravarthi'"                               
           <[email-masked]>, "'Madhu Babu   
           Brahmanapally'" <[email-masked]>, "'Terry L 
           Anderson'" <[email-masked]>                        
                                                              
 cc:       [email-masked](bcc: Sean Leahy/MAIN/MC1)          

Brian

---

From: [email-masked]
Date: Fri, 22 Jun 2001 08:39:04 -0400

I'm having trouble following your question.

The example we are discussing, trunk gateways, has digit analysis and call
control done
completely in the MGC; the MG has no role at all in these matters.  The
fact that digit
analysis takes some time in the MGC is, I believe, the reasons being
advanced for
starting with the originating MG and doing everything you can in advance of
determining
the terminating MG.  If the design of the MGC is such that it gets all the
information at
once (both ends), it can send out the optimal 2 transaction/4 command
sequence.

The issue is that you gain nothing by anticipating that you might need an
ephemeral.
Whether it turns out that you do (originating MG not equal terminating MG)
or you don't
(hairpin), putting the ephemeral in the context before you know doesn't
help anything.

It may or may not "work" in all MGs, but I don't see any reason to do it.

Maybe I'm missing something.

Brian

    -----Original Message-----
   From:   Leahy, Sean
   Sent:   Friday, June 22, 2001 4:09 AM
   To:     Rosen, Brian
   Cc:     [email-masked]
   Subject:  RE: Ephemeral Termination

     Brian,
          Just a question.

          There may be cases where Megaco is being used solely for bearer
     control and the call control/digit analysis is conducted at a layer
     above the Megaco protocol. In these circumstances, it is also possible
     that ephemerals are added and modified by command from the MGC when
     the bearer connection is actually between two physical terminations on
     the same Media Gateway. Is it altogether impossible for a Media
     Gateway to optimise such a hair-pin connection whilst maintaining the
     same model to the MGC ?

          Sean Leahy
          Marconi

     (Embedded image moved to file: pic24464.pcx)
     CN=Brian Rosen/OU=MAIN/O=MC1@MSEXCH on 21/06/2001 15:56:23

   |--------------------------------------------------------------------------------------------------------------------------|
   |                                                                                                                          |
   |                                                                                                                          |
   |                                                                                                                          |
   |--------------------------------------------------------------------------------------------------------------------------|

   |----------+-------------------------------------------------------------|
   |          |                                                             |
   |          |                                                             |
   |          |                                                             |
   |----------+-------------------------------------------------------------|
   |          |                                                             |
   | To:      | "'PSK Chakravarthi'" <[email-masked]>,    |
   |          | "'Madhu Babu Brahmanapally'" <[email-masked]>,       |
   |          | "'Terry L Anderson'" <[email-masked]>                       |
   |          |                                                             |
   |----------+-------------------------------------------------------------|
   |          |                                                             |
   | cc:      | [email-masked](bcc: Sean Leahy/MAIN/MC1)                   |
   |          |                                                             |
   |----------+-------------------------------------------------------------|
   |          |                                                             |
   |          |                                                             |
   |          |                                                             |
   |----------+-------------------------------------------------------------|
   |          |                                                             |
   | Subject: | RE: Ephemeral Termination                                   |
   |          |                                                             |
   |----------+-------------------------------------------------------------|

     (Embedded image moved to file: pic05705.pcx)
     I'm having trouble following your logic.

     difference in processing of half the number of messages will be
     substantial.

     Brian

---

From: "Sean Leahy" <[email-masked]>
Date: Fri, 22 Jun 2001 16:24:34 +0100

Brian,
     Briefly, the scenario that I was postulating was that the Call Control at
the MGC (or above the
MGC - depending on how you define an 'MGC' realisation) is separate from the
bearer control at the MGC. Thus
the MGC bearer signalling is independent enough from the call control/digit
analysis that it does not
allow the H.248 functionality to be told directly that the two physical
terminations are on the same MG
when it is first invoked (for the connection to termination A) from the call
control function.
     The MGC might work this out when it is invoked for the connection to
termination B, but there may
be a problem if there are two separate instances of the same MGC handling each
side of the connection.
     Thus the question remains - Is there any possibility for a Media Gateway to
optimise such a hair-pin
connection whilst maintaining the same model to the MGC ?
     Obviously, the alternative is to change both the call control and bearer
control layers to be able to harmonise
better to deal with hairpin connections. But it would be interesting to know if
you think optimisation at the MG is a possibility
that might mean this could be avoided, if it were so desired.

     Regards,
     Sean Leahy

From: Brian Rosen/MAIN/MC1@MSEXCH on 22/06/2001 13:39

To:   Sean Leahy/MAIN/MC1@MCMAIN
cc:   [email-masked]

The example we are discussing, trunk gateways, has digit analysis and call
control done
completely in the MGC; the MG has no role at all in these matters.  The fact
that digit
analysis takes some time in the MGC is, I believe, the reasons being advanced
for
starting with the originating MG and doing everything you can in advance of
determining
the terminating MG.  If the design of the MGC is such that it gets all the
information at
once (both ends), it can send out the optimal 2 transaction/4 command sequence.

The issue is that you gain nothing by anticipating that you might need an
ephemeral.
Whether it turns out that you do (originating MG not equal terminating MG) or
you don't
(hairpin), putting the ephemeral in the context before you know doesn't help
anything.

Brian

    -----Original Message-----
   From:   Leahy, Sean
   Sent:   Friday, June 22, 2001 4:09 AM
   To:     Rosen, Brian
   Cc:     [email-masked]
   Subject:  RE: Ephemeral Termination

     Brian,
          Just a question.

          There may be cases where Megaco is being used solely for bearer
     control and the call control/digit analysis is conducted at a layer above
     the Megaco protocol. In these circumstances, it is also possible that
     ephemerals are added and modified by command from the MGC when the bearer
     connection is actually between two physical terminations on the same Media
     Gateway. Is it altogether impossible for a Media Gateway to optimise such a
     hair-pin connection whilst maintaining the same model to the MGC ?

          Sean Leahy
          Marconi

     (Embedded image moved to file: pic28418.pcx)
     CN=Brian Rosen/OU=MAIN/O=MC1@MSEXCH on 21/06/2001 15:56:23
|------------------------------------------------------------------------------|
|                                                                              |
|                                                                              |
|                                                                              |
|------------------------------------------------------------------------------|

     (Embedded image moved to file: pic06763.pcx)
     I'm having trouble following your logic.

     Brian

---

From: [email-masked]
Date: Fri, 22 Jun 2001 11:59:45 -0400

Okay, so the problem you postulate is that there are TWO instances of an
MGC
handling the two sides of the connection and thus you don't know that the
same MG
is being used.

I'll leave the issue of how the two MGCs share the resources of the MG to
another discussion;
let's suppose for the moment that two virtual MGs are assigned one each to
the two
MGC instances -- is that close??

Now, in theory, anyway, no-one figure out that it's the same MG.  In that
case,
your MG better be able to send packets to itself.  Then, backing up a
little, it's the MG
that figures it out, in which case it has two contexts, each with two
terminations, and it
knows that in fact the two ephemerals are "connected" via the net.  It can,
in theory anyway,
fake the network connection and "do the right thing".  In this case, as far
as the MGCs
know, it IS going across the network; the MG is just optimizing the network
path!

Now we step back to your position, which is that, somehow, the two MGC
instances
discover this, and you want to know how they should handle that.  Is that
right?

Well, I must be dense or something, because I would say that the MGCs never
Add the ephemeral until they know what the other end is, and then they add
it with
all the right characteristics.   If the originating MGC instance
communicates with the
terminating MGC instance and discovers that both ends are in the same MG,
in my
postulated Virtual MG scenario they CAN'T actually do the really right
thing, which is
to create one context with both physical terminations, because there is no
way for
either of the two MGCs to access the other physical termination, and one
MGC can't
use the other MGC's ContextId.  So, you HAVE to let the MG do it, if at
all.

So, if the real bottom line question you are asking is if I have a
circumstance where
the physical MG is presented with a circumstance where it has two, 2
termination
contexts, where the ephemerals are cross connected, can it optimize that to
make a
hairpin without telling the MGCs what is happening, I'd say yes, but it has
to do
all of the right thing.  This would include, for example, supplying some
appropriate
statistics for the ephemerals!

If you are asking if I ever see a circumstance where it makes sense to have
a
3 termination context with two physicals and an ephemeral, where the
ephemeral
isn't actually "active" (doesn't have a remote), then I would say, no I
don't see how that
ever makes sense.  Would it work?  That is, should an MG actually allow it?
I don't know;
it's really an error (incomplete characterization of the ephemeral), but
that is allowed
at least transiently.  I could see some timeout, but that would not be a
"standards based"
thing.  So, I expect in most cases it actually would work.  YMMV.

Brian

    -----Original Message-----
   From:   Leahy, Sean
   Sent:   Friday, June 22, 2001 11:25 AM
   To:     Rosen, Brian
   Cc:     [email-masked]
   Subject:  RE: Ephemeral Termination

     Brian,
          Briefly, the scenario that I was postulating was that the Call
     Control at the MGC (or above the
     MGC - depending on how you define an 'MGC' realisation) is separate
     from the bearer control at the MGC. Thus
     the MGC bearer signalling is independent enough from the call
     control/digit analysis that it does not
     allow the H.248 functionality to be told directly that the two
     physical terminations are on the same MG
     when it is first invoked (for the connection to termination A) from
     the call control function.
          The MGC might work this out when it is invoked for the connection
     to termination B, but there may
     be a problem if there are two separate instances of the same MGC
     handling each side of the connection.
          Thus the question remains - Is there any possibility for a Media
     Gateway to optimise such a hair-pin
     connection whilst maintaining the same model to the MGC ?
          Obviously, the alternative is to change both the call control and
     bearer control layers to be able to harmonise
     better to deal with hairpin connections. But it would be interesting
     to know if you think optimisation at the MG is a possibility
     that might mean this could be avoided, if it were so desired.

          Regards,
          Sean Leahy

     The example we are discussing, trunk gateways, has digit analysis and
     call control done
     completely in the MGC; the MG has no role at all in these matters.
     The fact that digit
     analysis takes some time in the MGC is, I believe, the reasons being
     advanced for
     starting with the originating MG and doing everything you can in
     advance of determining
     the terminating MG.  If the design of the MGC is such that it gets all
     the information at
     once (both ends), it can send out the optimal 2 transaction/4 command
     sequence.

     The issue is that you gain nothing by anticipating that you might need
     an ephemeral.
     Whether it turns out that you do (originating MG not equal terminating
     MG) or you don't
     (hairpin), putting the ephemeral in the context before you know
     doesn't help anything.

     It may or may not "work" in all MGs, but I don't see any reason to do
     it.

     Brian

         -----Original Message-----
        From:     Leahy, Sean
        Sent:     Friday, June 22, 2001 4:09 AM
        To:  Rosen, Brian
        Cc:  [email-masked]
        Subject:  RE: Ephemeral Termination

          Brian,
               Just a question.

               There may be cases where Megaco is being used solely for
          bearer control and the call control/digit analysis is conducted
          at a layer above the Megaco protocol. In these circumstances, it
          is also possible that ephemerals are added and modified by
          command from the MGC when the bearer connection is actually
          between two physical terminations on the same Media Gateway. Is
          it altogether impossible for a Media Gateway to optimise such a
          hair-pin connection whilst maintaining the same model to the MGC
          ?

               Sean Leahy
               Marconi

           << OLE Object: Picture (Device Independent Bitmap) >>
          CN=Brian Rosen/OU=MAIN/O=MC1@MSEXCH on 21/06/2001 15:56:23

|----------------------------------------------------------------------------------------------------------------------------------------------------|
|                                                                                                                                                    |
|                                                                                                                                                    |
|                                                                                                                                                    |
|----------------------------------------------------------------------------------------------------------------------------------------------------|

   |------------+-------------------------------------------------------------------------|
   |            |                                                                         |
   |            |                                                                         |
   |            |                                                                         |
   |------------+-------------------------------------------------------------------------|
   |            |                                                                         |
   | To:        | "'PSK Chakravarthi'" <[email-masked]>, "'Madhu Babu   |
   |            | Brahmanapally'" <[email-masked]>, "'Terry L Anderson'"           |
   |            | <[email-masked]>                                                        |
   |            |                                                                         |
   |------------+-------------------------------------------------------------------------|
   |            |                                                                         |
   | cc:        | [email-masked](bcc: Sean Leahy/MAIN/MC1)                               |
   |            |                                                                         |
   |------------+-------------------------------------------------------------------------|
   |            |                                                                         |
   |            |                                                                         |
   |            |                                                                         |
   |------------+-------------------------------------------------------------------------|
   |            |                                                                         |
   | Subject:   | RE: Ephemeral Termination                                               |
   |            |                                                                         |
   |------------+-------------------------------------------------------------------------|

           << OLE Object: Picture (Device Independent Bitmap) >>
          I'm having trouble following your logic.

          you would not have the correct remote SDP, and therefore you
          would

          Brian

          > From: PSK Chakravarthi
          [mailto:[email-masked]]
          > > > From: PSK Chakravarthi
          [mailto:[email-masked]]

---

From: [email-masked]
Date: Fri, 22 Jun 2001 12:42:05 -0400

Does an MG that 'discovers' that it has 2 ephemerals that are "connected" 
via the net and bypasses the network connection pose a problem related to 
CALEA/wiretapping?  In other words, if the MGC instructs the MG to use the 
network, shouldn't the MG comply?

DaveS.

[email-masked]
Sent by: [email-masked]
06/22/2001 11:59 AM

        To:     [email-masked]
        cc:     [email-masked]
        Subject:        RE: Ephemeral Termination

Now, in theory, anyway, no-one figure out that it's the same MG.  In that
case,
your MG better be able to send packets to itself.  Then, backing up a
little, it's the MG
that figures it out, in which case it has two contexts, each with two
terminations, and it
knows that in fact the two ephemerals are "connected" via the net.  It 
can,
in theory anyway,
fake the network connection and "do the right thing".  In this case, as 
far
as the MGCs
know, it IS going across the network; the MG is just optimizing the 
network
path!

Well, I must be dense or something, because I would say that the MGCs 
never

So, if the real bottom line question you are asking is if I have a
circumstance where
the physical MG is presented with a circumstance where it has two, 2
termination
contexts, where the ephemerals are cross connected, can it optimize that 
to
make a
hairpin without telling the MGCs what is happening, I'd say yes, but it 
has
to do
all of the right thing.  This would include, for example, supplying some
appropriate
statistics for the ephemerals!

If you are asking if I ever see a circumstance where it makes sense to 
have
a
3 termination context with two physicals and an ephemeral, where the
ephemeral
isn't actually "active" (doesn't have a remote), then I would say, no I
don't see how that
ever makes sense.  Would it work?  That is, should an MG actually allow 
it?
I don't know;
it's really an error (incomplete characterization of the ephemeral), but
that is allowed
at least transiently.  I could see some timeout, but that would not be a
"standards based"
thing.  So, I expect in most cases it actually would work.  YMMV.

Brian

    -----Original Message-----
   From:   Leahy, Sean
   Sent:   Friday, June 22, 2001 11:25 AM
   To:     Rosen, Brian
   Cc:     [email-masked]
   Subject:  RE: Ephemeral Termination

     Brian,
          The MGC might work this out when it is invoked for the 
connection
          Obviously, the alternative is to change both the call control 

          Regards,
          Sean Leahy

     the terminating MG.  If the design of the MGC is such that it gets 
all

     The issue is that you gain nothing by anticipating that you might 
need
     an ephemeral.
     Whether it turns out that you do (originating MG not equal 
terminating
     MG) or you don't
     (hairpin), putting the ephemeral in the context before you know
     doesn't help anything.

     Brian

         -----Original Message-----
        From:     Leahy, Sean
        Sent:     Friday, June 22, 2001 4:09 AM
        To:  Rosen, Brian
        Cc:  [email-masked]
        Subject:  RE: Ephemeral Termination

          Brian,
               Just a question.

               Sean Leahy
               Marconi

 
 
|------------+-------------------------------------------------------------------------|
   |            |                |
   | To:        | "'PSK Chakravarthi'" <[email-masked]>, 
"'Madhu Babu   |
   |            | Brahmanapally'" <[email-masked]>, "'Terry L 
Anderson'"           |
   |            | <[email-masked]>                |
   |            |                |

 

          send message 1 after digit analysis, because then the 
originating

          Brian

          > 1. Soon after receiving IAM send ADD command to the 
originating
          MG for
          > > > > > there is no need to create an ephemeral termination 
(as
          PSK
          > > > > > [mailto:[email-masked]]On Behalf 
Of
          Terry
          > > > > > > 2. MGC now finds that call is terminating on the 
same
          MG.
          > > > > > Also MGC knows
          > > > > > that
          > > > > > > MG is capable of adding two TDMs to the same 
context.
          At
          > > > > > > Simply sending ADD for new TDM to the same context 
is
          > > > sufficient?
          > > > > > sending the ADD, in step 1c, but if since step c 
(which
          you

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 22 Jun 2001 12:58:22 -0400

Could be.  That is a system design issue.
I suspect that in that case you need to force packets to flow upstream.
In some operating systems, a packet sent to yourself doesn't get on
the net.  Might need to force the flow to always go through the
access router.  There are a couple of ways to do that.

Brian  

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, June 22, 2001 12:42 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> |-------------------------------------------------------------
> --------------------------------------------------------------
> -------------------------|
> |   |
> |   |
> |   |
> |-------------------------------------------------------------
> --------------------------------------------------------------
> -------------------------|
> 
> 
> 
> 
>  
>           >    c) Setting SDP remote as Local returned by the 
> originating
>           MG.
> <[email-masked]>;
>           > "'Madhu Babu
>           > > > > you negotiate the SDP, you can't reserve 
> bandwidth.  You
>           can't
>           > > > > > 1) If Ephemeral termination is created 
> before digit
>           analysis,
>           > > > > > situation may
>           > > > > > this has the advantage that the call wont 
> be dropped
>           due
>           > > > to lack of
>           > > > > > resource, as ephemeral resources are 
> pre-reserved at
>           the MG.
>           > > > > > (in case Add
>           > > > > > of all situation where destination user 
> may/may not
>           connected
>           > > > > > to the same
>           > > > > > In case of 1) if the call doesn't mature, 
> reserving 
> the
>           > > > > > resources doesn't
>           > > > > > gain anything. Consideration that the 
> destination user
>           on the
>           > > > > > same MG is
>           > > > > > > If the originating and terminating 
> termination IDs
>           are on
>           > > > > > the same gateway
>           > > > > > and
>           > > > > > > gateway supports two TDM terminations 
> in a context,
>           is it
>           > > > > > required to
>           > > > > > craete a
>           > > > > > > Is it required to SUBTRACT the 
> ephemeral termination
>           and
>           > > > > > send ADD for
>           > > > > > adding new

---

From: [email-masked]
Date: Fri, 22 Jun 2001 14:38:08 -0400

Oops, I was only thinking of ATM, where the MG was asked to make a hairpin 
SVC.   I don't think anything other than intelligence in the MG would 
prevent cells from going out on the wire in that case!

DaveS.

"Rosen, Brian" <[email-masked]>
Sent by: [email-masked]
06/22/2001 12:58 PM

        To:     "[email-masked]'" <[email-masked]>
        cc:     [email-masked], [email-masked], "Leahy, Sean" 
<[email-masked]>
        Subject:        RE: Ephemeral Termination

Brian

---

From: "Sean Leahy" <[email-masked]>
Date: Mon, 25 Jun 2001 09:18:27 +0100

Brian,
     Thanks for the reply. Yes indeed, and as you suggest 'the real bottom line
question'  was
"if the physical MG has two, 2 termination contexts, where the ephemerals are
cross connected,
can it optimize that to make a hairpin without telling the MGCs what is
happening". I understand that
your answer is 'Yes...at least in principle".

     I had not considered that if such a solution was adopted the 2 MGC
instances would then
"somehow discover" this. The whole idea as far as I was concerned was that this
optimisation would
be invisible to the MGC.

     Incidentally, I believe that in addition to the reasons that you give about
the MGC Instances
not being able to share the same ContextId  or physical terminations, the MGC
Instances probably
cannot resolve the optimisation at their own level because each instance does
not have the full view
of the connection but only a partial one-sided view of it (although for recovery
purposes they might hold
more information about the full connection then they think they do - if you see
what I mean).

     Thanks again,
     Sean

Brian Rosen wrote:

Okay, so the problem you postulate is that there are TWO instances of an MGC
handling the two sides of the connection and thus you don't know that the same
MG
is being used.

I'll leave the issue of how the two MGCs share the resources of the MG to
another discussion;
let's suppose for the moment that two virtual MGs are assigned one each to the
two
MGC instances -- is that close??

Now, in theory, anyway, no-one figure out that it's the same MG.  In that case,
your MG better be able to send packets to itself.  Then, backing up a little,
it's the MG
that figures it out, in which case it has two contexts, each with two
terminations, and it
knows that in fact the two ephemerals are "connected" via the net.  It can, in
theory anyway,
fake the network connection and "do the right thing".  In this case, as far as
the MGCs
know, it IS going across the network; the MG is just optimizing the network
path!

Now we step back to your position, which is that, somehow, the two MGC instances
discover this, and you want to know how they should handle that.  Is that right?

Well, I must be dense or something, because I would say that the MGCs never
Add the ephemeral until they know what the other end is, and then they add it
with
all the right characteristics.   If the originating MGC instance communicates
with the
terminating MGC instance and discovers that both ends are in the same MG, in my
postulated Virtual MG scenario they CAN'T actually do the really right thing,
which is
to create one context with both physical terminations, because there is no way
for
either of the two MGCs to access the other physical termination, and one MGC
can't
use the other MGC's ContextId.  So, you HAVE to let the MG do it, if at all.

So, if the real bottom line question you are asking is if I have a circumstance
where
the physical MG is presented with a circumstance where it has two, 2 termination
contexts, where the ephemerals are cross connected, can it optimize that to make
a
hairpin without telling the MGCs what is happening, I'd say yes, but it has to
do
all of the right thing.  This would include, for example, supplying some
appropriate
statistics for the ephemerals!

If you are asking if I ever see a circumstance where it makes sense to have a
3 termination context with two physicals and an ephemeral, where the ephemeral
isn't actually "active" (doesn't have a remote), then I would say, no I don't
see how that
ever makes sense.  Would it work?  That is, should an MG actually allow it?  I
don't know;
it's really an error (incomplete characterization of the ephemeral), but that is
allowed
at least transiently.  I could see some timeout, but that would not be a
"standards based"
thing.  So, I expect in most cases it actually would work.  YMMV.

Brian