Subject: Re: H.323 with ATM

From: [email-masked]
Date: Wed, 21 Apr 1999 08:26:16 -0400

For VoIP using H.323; Annex C of the H.323 specification
describes how to implement VoIP for ATM. A better mailing
list  to discuss H.323 however will be [email-masked].

Best Regards,

- Greg Boop
   Mgr - VoIP Development
   IBM NHD
   RTP, NC, USA
   +1 919 254 0319
    [email-masked]

"Eric Ho" <[email-masked]> on 04/20/99 10:53:30 PM

To:   "IPTEL IETF Mailing List" <[email-masked]>
cc:   "IPTEL IETF Mailing List" <[email-masked]> (bcc:
      Gregory Boop/Raleigh/IBM)
Subject:  H.323 with ATM

Hi,

Could anyone please advise how VoIP is going to run over ATM
(i.e., what kind of encapsulation or native ATM)?

Thanks in advance!

eh

=====================================================================
Eric Ho                                         Direct: +852-27222766
FORE Systems, Inc.                                Main: +852-27222722

---------
This message came from the IETF IPTEL Working Group Mailing List.

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Abhishek Singh <[email-masked]>
Date: Wed, 21 Apr 1999 07:11:40 -0700 (PDT)

Hi Eric,

There is work going on in the ATM Forum and it is
called RMOA(realtime multimedia over ATM). Seems
pretty good way for H.323 transport over ATM. Not
aware of SIP efforts though.

cheers
Abhishek

> This message came from the IETF IPTEL Working Group

===
Go to 
http://abhishekrs.eCode.com 
to pick up my online Business Card.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---------

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 26 Apr 1999 11:06:40 -0500

> but from h.323 and h.323 annex c you can derive the same case as is
> described in the atm forum document.  as i read the document, the c/d 
> effectively implements the gatekeeper routed model for h.225/h.245 
> channels.

Yes. That is what we did. There are some additional complications on the
signalling side since in Annex C, the terminal "knows" when to set-up
SVCs. In the ATM Forum specification, the gateway relies on signalling
to set-up the SVCs.

The intention was not to superseed the Annex C specification, but to 
extend its application to cases involving ATM gateways, and also to add
header compression. That is the reason why it will likely be included in 
the next version of H.323 (probably as a reference).

> i'm a bit confused about the question but i would say that the
> answer is most definitely; if you're going to split call control
> signalling and bearer connection control signalling, then you need
> some means of correlating the two.  i don't think this was the issue
> that jonathan had in mind but i say this because in the version of
> the atm forum contribution that i have, there was no mention of use
> of the broadband high layer information element or generic identifier
> transport information element to do this correlation.  let me qualify
> this by saying that my copy is from october...

Final version (April) includes the GIT. The reason why the B-HLI was
not in there was because we knew from ITU-T SG11 that Annex C's use
of B-HLI was troublesome and something had to be changed.

> as far as using rsvp or diffserv as a trigger for svc establishment,
> i would think that you would want to be able to do that as well if
> the intent is to have some means of providing end-to-end qos across
> atm and ip network boundaries.  but this is the case of doing ip over
> atm which annex c sought to avoid.  the annex c approach does get into
> application layer processing at the interworking node as jonathan
> mentioned, but you save the ip overhead.  there is an 
> internet draft by 
> garrett, et. al. which describes the interworking of controlled load 
> service and guaranteed service with atm.

Agreed. There are probably cases for both approaches. This is what I
meant origninally.

---------

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 26 Apr 1999 12:16:02 -0400

> No, I don't think you need this explicit association. For regular IP
> over ATM, its completely absent. Remember, this case here is 
> not ATM end
> to end (in which case you *would* need it), but rather IP on the
> periphery, with an ATM cloud in the middle (at least, this is my
> interpretation, correct me if I have completely misunderstood 
> the model
> here). When the RSVP hits the ATM cloud, it causes an SVC to be set up
> (of course, RSVP and UNI signaling are in the opposite directions, but
> that can be handled).  RTP packets come in, are sent through this SVC
> (possibly being compressed), and then completely reproduced (IP header
> and all), and the far end. They are then carried over normal IP to the
> end. The recipient wouldn't even notice that there was an SVC. 

Yes, the model is the ATM cloud in the middle, the IP networks on the edges.

> The great advantage of using RSVP or diffserv as a trigger for SVC
> establishment is that is application independent. Lets not forget that
> IP telephony is only one of many IP apps which will need QoS. 
> By making
> this QoS mechanism H.323 specific, you narrow the scope of the service
> that can be provided (only H.323, and only the version you support),
> make this edge box more complex, and in general break the end to end
> model.

We looked at using lower-layer mechanism at the beginning, but couldn't find
satisfactory methods. RSVP was felt as not being sufficiently deployed,
diffserv
didn't exist at the time.

One of the issues was how to force the connection to go through the gateway.

That being said, I would agree with you that there are probably ways to
set-up 
individual SVCs based on some lower-level protocols as you mentioned.

The H.245 method has the advantage of being very precise on what type of
connection
will be required at the SVC level. It does, however, as you note, have the 
disadvantage that the gateway has to maintain a substantial amount of
software (the
H.323 stack). As such, it would be a relatively complex device.

---------