June 1999 - sg16-avd - lists.packetizer.com

Re: H.323 Annex E and H.225.0 Annex G Upload
by Sakae OKUBO 02 Jun '99

02 Jun '99

Dear Mr. Moscovici, LM> I have uploaded the decided texts of H.323 Annex E and H.225.0 Annex G to LM> the PictureTel site. LM> The files are named accordingly. They have been moved to the following place: ftp://standard.pictel.com/avc-site/9905_San/H.225.0_Annex_G_990528.zip or http://standard.pictel.com/ftp/avc-site/9905_San/H.225.0_Annex_G_990528.zip ftp://standard.pictel.com/avc-site/9905_San/H.323_Annex_E_990528.zip or http://standard.pictel.com/ftp/avc-site/9905_San/H.323_Annex_E_990528.zip Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Re: SG16 Q13
by Lior Moscovici 02 Jun '99

02 Jun '99

Some comments: 1. The reference points naming is confusing: either TIPHON B, CA, CB, DA, DB, or SG11 i IFx. I would stick to the second one, to have common language. 2. Although we talked about it, Ed, I don't remember the point in IF7, between the MGC and the SCP via SC GF, bypassing the GK. The main path has to go through the GK anyway, and reasoning for that has to be given: the GK is the service manager and co-ordinator for the IP network. It decides whether a trigger can be handled inside or has to be diverted to the external SCP. 3. You refer to "peering SCPs". Purely SS7-wise, INAP is not peer-to-peer, so the GK is both SCP client (i.e. SSF) and server (i.e. SCF towards the SCN SSFs), but not at the same time. 4. The statement on the PINT server is a bit vague. I would rather say: "the PINT server is merely a web interface for controling SCN calls, thus has less relevance to H.323 that deals with multimedia over IP (packetized networks). 5. Direct routed call model has to be reflected in figure 3, or on a separate figure. Note that the fact that the GW is decomposed implies GRC, since the signaling and media pass on two different nodes, so the example has to be of a client terminal, rather than a GW. Lior -------- On 05/28/99 10:40 PM GMT "Edgar Martinez [1]" <martinze(a)CIG.MOT.COM> wrote: Dear SG16 Q13, I am sending this out for comments. On a proposed response to SG11. -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 TIPHON & Other Stds -- http://www.cig.mot.com/~martinze/

1 0

Re: [Q] H.261 GOB packetizing
by Roni Even 02 Jun '99

02 Jun '99

There is no limitation of one GOB per packet. The limitation is that a GOB will not break between packets unless the macro block is longer then the MTU, in that case you can break the GOB. There is no specific structure for a packet with more then one GOB, it is as defined in H.261. The only important information is that all packets of the same frame will have the same time stamp. ********************************************** Roni Even VP Product Marketing Accord Video Telecommunication Email: roni_e(a)accord.co.il Tel: +972-3-9251412 Fax: +972-3-9211571 *************************************************** > -----Original Message----- > From: Lee Hyoung soo [SMTP:soo@DESKVIEW.NADA.CO.KR] > Sent: Wednesday, June 02, 1999 2:52 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Q] H.261 GOB packetizing > > Dear All, > > I have some problem to packetize H.261 GOB into RTP packet. There are > too many GOB's to packetize only one GOB into one RTP packet. > > Can I pack two or more H.261 GOB's in one RTP packet? > And I want to know the structure of packet which includes two or more > H.261 GOB's. > > Any comment will be appreciated. > > soo. > > > > -- > Nada Research Co., Ltd. Korea > TEL : 82-2-525-3941 > > Lee Hyoung soo. > > mailto:soo@DeskView.nada.co.kr

1 0

Re: Quick report of the SG16 meeting in Santiago
by Sakae OKUBO 02 Jun '99

02 Jun '99

Dea Mr. Audet, FA> > Dear Q.12-14 experts, FA> > FA> > This is to draw your attention to some items from the outcome of SG16 FA> > meeting in Santiago. FA> > FA> > 1. Draft Recommendations for Decision FA> > FA> > All have been decided as intended. Annex G to H.222.0 has received US FA> FA> Do you mean H.225.0 instead of H.222.0? Thank you for your advice. Yes, it should read Annex G to H.225.0. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

[Q] H.261 GOB packetizing
by Lee Hyoung soo 02 Jun '99

02 Jun '99

Dear All, I have some problem to packetize H.261 GOB into RTP packet. There are too many GOB's to packetize only one GOB into one RTP packet. Can I pack two or more H.261 GOB's in one RTP packet? And I want to know the structure of packet which includes two or more H.261 GOB's. Any comment will be appreciated. soo. -- Nada Research Co., Ltd. Korea TEL : 82-2-525-3941 Lee Hyoung soo. mailto:soo@DeskView.nada.co.kr

1 0

Re: H.323v3 and Implementers Guide
by Sakae OKUBO 01 Jun '99

01 Jun '99

Dear Mr. Jones, PJ> Mr. Okubo, PJ> PJ> I have attached draft copies of the H.323v3 document and Implementers PJ> Guide to this e-mail. If you get an opportunity, I would like to ask PJ> that you post them to the AVC Santiago directory so that others may PJ> review the documents. The two files have been placed at the PictureTel ftp site as follows: ftp://standard.pictel.com/avc-site/9905_San/H323v3_990528.zip or http://standard.pictel.com/ftp/avc-site/9905_San/H323v3_990528.zip ftp://standard.pictel.com/avc-site/9905_San/H323_impguide_990528.zip or http://standard.pictel.com/ftp/avc-site/9905_San/H323_impguide_990528.zip Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0