Subject: Re: ATM SVC call binding issue in MEGACO

From: Faad Ghoraishi <[email-masked]>
Date: Mon, 25 Oct 1999 17:07:05 -0400

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)
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: Stephen Terrill <[email-masked]>
Date: Tue, 26 Oct 1999 08:35:09 +0200

Hi Faad,

I feel that the whole SVC handling has to be further detailed in a package.  It would be benificial if there was a common way to handle the establishment of SVCs as well as AAL2 circuits using Q.2630.1 signalling - ie that is with an address.

If we look at Q.BICC, you will see that there is an identifier termed BNC-id (which is a bearer network connection id), and is carried in the call level as well as the bearer level.  In the bearer it would be carried in a new recommendation Q.2941.3 (for DSS2, B-ISUP - I assume PNNI will follow suite), or the SUGR parameter in Q.2630.1 signalling.  In this application, it would be a 4octect integer.

This could be handled in a package - I fear that the termination id would not be sufficient as it is a size that is upto the media gateway to define, and the BNC-id is something that the signalling protocols define.

For other applications (such as SIP or H.323) I am not sure of the best approach -- brian has initiated this discussion and I shall be intersted to see where it leads.

Regards,

..//Steve

---

From: Michael Brown <[email-masked]>
Date: Tue, 26 Oct 1999 11:04:16 -0400

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