Subject: Re: ATM SVC call binding issue in MEGACO

From: Brian Rosen <[email-masked]>
Date: Mon, 25 Oct 1999 16:30:40 -0400

I agree with Steven's approach - using a bearer correlation identifier, but
see a problem - it is dependent on inter MGC signalling.  BICC explicitly
defines it. SIP has a CallID that could be used I think.  Is there something
equivalent in H.323?

Brian

> -----Original Message-----
> From: Stephen Terrill [mailto:[email-masked]]
> Sent: Monday, October 25, 1999 4:11 PM
> To: [email-masked]
> Subject: Re: ATM SVC call binding issue in MEGACO
>
>
> Hi Faad,
>
> I would like to see that the solution can interworking with
> existing (or devoloping) protocols such as Q.BICC
>
> The terminatin id could be one approach.  A further approach
> is to include the the details of the binding informating in a
> package - a package wich should handle the both the
> initiating and terminating id.
>
> Regards,
>
> ..//Steve
>
> Faad Ghoraishi wrote:
>
> > Has anyone addressed the call flow for  an
> > ATM SVC connection using MEGACO.
> >
> > Specifically, what is the binding paramter that
> > binds an incoming/outgoing SVC ATM call with the
> > MEGACO signaling messages within the MG.
> > For example, how does the terminating MG (i.e, Trunk Gateway),
> > knows that an incoming ATM SVC call is related to a call
> >  with TerminationID=xxx and ContexID=yyy?
> > One way to do this is to send the far end MG's TerminationID
> > within the ATM UNI call setup message, so when it receives the
> > ATM SVC call setup message, it will know how to bind this
> > call with a particular ContextID.
> >
> > How is this function emplimented within MEGACO. Should
> > there be an Event defined for looking in a particular ATM UNI
> > message parameter and sending this info up to the MGC?
> >
> > Any suggestions?
> >
> > Thanks,
> >
> > Faad Ghoraishi
> > Telcordia Tech. Inc
> > USA
>

---

From: Faad Ghoraishi <[email-masked]>
Date: Mon, 25 Oct 1999 16:59:39 -0400

Hi Brian:

Where is this "bearer correlation identifier"?
Is this a MEGACO or Q.BICC parameter?
Is this or a similar parameter also in the ATM UNI
setup message?

Also, the problem I envision in MEGACO setting up
an ATM SVC connection, in addition to getting
the binding parameters across, is how does the Originating MG
wait until this binding info is delivered to the Terminating
MG before it initiates the ATM SVC call.
Unlike RTP, ATM SVC calls will initiate call setup as soon
at the MG gets an Add command with ATM SVC descriptor.

Faad

Brian Rosen <[email-masked]> on 10/25/99 04:30:40 PM

To:   "'Stephen Terrill'" <[email-masked]>, "'Faad Ghoraishi'"
      <[email-masked]>, [email-masked]
cc:    (bcc: Faad Ghoraishi/Telcordia)
Subject:  RE: ATM SVC call binding issue in MEGACO

Brian

---

From: "Jepsen, Tom" <[email-masked]>
Date: Tue, 26 Oct 1999 14:38:14 -0400

> at the MG gets an Add command with ATM SVC descriptor.
        [Jepsen, Tom]  My question is: at what point does the "ephemeral"
termination exist for an SVC ATM connection? (This would not be an issue for
a PVC ATM connection, which would be similar to RTP, i.e. the termination is
either there or it is not.)  For an SVC ATM connection, the Q.2931 signaling
must complete successfully before packets can be sent or received.  If you
create the termination before the signaling is completed (i.e. before  the
initiating side receives a CONNECT), you would then have to tear down the
termination if the connection attempt was not successful.  Should a
termination be created before the signaling is initiated? Or after the
signaling completes successfully?  I would be interested in hearing other's
opinions.

        Regards
        Tom Jepsen
        Fujitsu Network Communications
        1000 St. Albans Drive
        Raleigh, NC 27609 USA
        919.790.3439

---

From: "Drage, Keith" <[email-masked]>
Date: Wed, 27 Oct 1999 10:44:05 +0100

I have not yet been able to review the referenced contribution, as I am (as
usual) unable to access the referenced site, and have never been able to
find out why. However, I would like to voice one concern that does need to
be checked.

Before you all start reusing the BNC-ID, please check the conditions for
access to that identifier are met.

For ATM, it is available only to the addressed endpoints of the bearer,
because it is defined in the Generic identifier transport information
element, which is available only to the addressed endpoints. This works for
Q.BICC, because the ICNs are the addressed endpoints of the ATM connections.

So, fine if you are using it under a similar architecture to Q.BICC, not so
if you are doing binding at intermediate points between the addressed
endpoints of the bearer.

Keith Drage

> ---------------------------------------------------------------
> Keith Drage ([email-masked])
> Siemens Communications Limited,
> Technology Drive, Beeston, Nottingham NG9 1LA, UK
> Tel: +44 115 943 4991   Fax: +44 115 943 4992
> ---------------------------------------------------------------
> Internet communications are not secure and therefore Siemens
> Communications Limited does not accept legal responsibility for the
> contents of this message. Any views or opinions presented are solely
> those of the author and do not necessarily represent those of Siemens
> Communications Limited unless otherwise specifically stated.
>

-----Original Message-----
From: Michael Brown [mailto:[email-masked]]
Sent: Tuesday, October 26, 1999 4:04 PM
To: [email-masked]
Subject: Re: ATM SVC call binding issue in MEGACO

Sophia Scoggins and I have put together an I-D which has some proposals
related to
the binding of the SVCs which recommend using the BNC-ID. The proposal
addresses
SIP by suggesting that the BNC-ID can be carried in SDP. We have also
included
some high level call walkthroughs. It has not been added to the I-D
directory
yet.  It was submitted prior to the cutoff on Friday, so it should be there
soon.
It also addresses the initiation issues by defining signals and events to
drive
the setup behavior.

Until it is in the I-D directory you can access it at :
ftp://standards.nortelnetworks.com/megaco/docs/Wash99/draft-scoggins-megaco-
atmimp-00.txt

Michael Brown

Faad Ghoraishi wrote:

> Stephen:
>
> What do you mean by "..include details of the binding
> informating in a package"?
> The MGC has the TermID from the originating MG and
> will get the TermID from the terminating MG (These info will be in the
> Add Ack messages from the MGs).  This assumes a single MGC
> in contorl of end-to-end connction.
>
> Are you suggesting more
> binding info than the two TerminationIDs.
>
> Faad
> **************
>
> Stephen Terrill <[email-masked]> on 10/25/99 04:11:07 PM
>
> To:   Faad Ghoraishi <[email-masked]>
> cc:   [email-masked] (bcc: Faad Ghoraishi/Telcordia)
> I would like to see that the solution can interworking with existing (or
> devoloping) protocols such as Q.BICC
>
> The terminatin id could be one approach.  A further approach is to include
the
> the details of the binding informating in a package - a package wich
should
> handle the both the initiating and terminating id.
>
> Regards,
>
> ..//Steve
>
> Faad Ghoraishi wrote:
>