March 2000 - sg16-avd - lists.packetizer.com

Re: proposal for SIP as single call control protocol in 3GPP
by Callaghan, Robert 06 Mar '00

06 Mar '00

It should be noted that an important phase is contained in this document. It states that SIP is "position SIP as an ideal protocol to modify and enhance to meet the R2000 requirements." This can be translated into "We want our own protocol based in SIP." It will be interest to see if the results are fully compatible with RFC 2546 (SIP). Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information and Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Michaely, Boaz [mailto:Boaz_Michaely@ICOMVERSE.COM] Sent: Monday, March 06, 2000 2:54 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: proposal for SIP as single call control protocol in 3GPP All, This proposal comes from: AT&T, BT, Japan Telecom, Lucent, Nokia, Nortel, Rogers Wireless, T-Mobil, Telenor, Telia. For those who are unaware, Release 2000 is conceived as THE most important activity regarding the future of VoIP in the sense that in a few short years wireless will become the dominant way of communication (more than wireline). 3GPP now discusses "Release 2000" which is the architecture for that future mobile network, where everything is over IP, including the media. This material is for discussion in Tokyo, March 6-9. Thought you should know, Boaz Boaz Michaely Senior System Architect, Corporate Comverse Network Systems Tel: +972 (3) 766-3844 , Mobile +972 (50) 39-30-17 http://people.itu.int/~michaely mailto:boaz_michaely@comverse.com > -----Original Message----- > From: Lobley,NC,Nigel,NZCA R [mailto:nigel.lobley@BT.COM] > Sent: Friday, March 03, 2000 1:40 PM > To: 3GPP_TSG_SA_WG2(a)LIST.ETSI.FR > Subject: Inputs from BT and a number of companies > > > Dear all > > Please find attached a couple of papers for S2 next week. > > See you in Japan > > Nigel >

1 0

proposal for SIP as single call control protocol in 3GPP
by Michaely, Boaz 06 Mar '00

06 Mar '00

All, This proposal comes from: AT&T, BT, Japan Telecom, Lucent, Nokia, Nortel, Rogers Wireless, T-Mobil, Telenor, Telia. For those who are unaware, Release 2000 is conceived as THE most important activity regarding the future of VoIP in the sense that in a few short years wireless will become the dominant way of communication (more than wireline). 3GPP now discusses "Release 2000" which is the architecture for that future mobile network, where everything is over IP, including the media. This material is for discussion in Tokyo, March 6-9. Thought you should know, Boaz Boaz Michaely Senior System Architect, Corporate Comverse Network Systems Tel: +972 (3) 766-3844 , Mobile +972 (50) 39-30-17 http://people.itu.int/~michaely mailto:boaz_michaely@comverse.com > -----Original Message----- > From: Lobley,NC,Nigel,NZCA R [mailto:nigel.lobley@BT.COM] > Sent: Friday, March 03, 2000 1:40 PM > To: 3GPP_TSG_SA_WG2(a)LIST.ETSI.FR > Subject: Inputs from BT and a number of companies > > > Dear all > > Please find attached a couple of papers for S2 next week. > > See you in Japan > > Nigel >

1 0

FW: Please upload the decided/determined/approved texts
by Mike Buckley 06 Mar '00

06 Mar '00

I have uploaded TD126rev1 (WP2) from the last meeting which contains the draft text of the new Annex N (QoS) of H.323. Mike Buckley (editor) ____________________ Begin Forwarded Message __________________________ Date: Sat Feb 19 02:34:29 +0900 2000 From: internet!TIES.ITU.INT!sakae.okubo (Sakae OKUBO) Subject: Please upload the decided/determined/approved texts To: internet!MAILBAG.INTEL.COM!ITU-SG16 Content-Type: Text Content-Length: 703 Dear Editors, Could you please upload your documents of decision, determination or approval at the /Incoming of the PictureTel ftp site? Please make an announce through the reflector when you have uploaded your documents. Best regards, Sakae OKUBO *********************************************************** 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 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

2 1

Re: H.225 Annex G
by Michael Fortinsky 05 Mar '00

05 Mar '00

Hi Greg, H.225.0 Annex G provides more than just address resolution. A short list of the functionality Annex G supports includes: - support for different interdomain architectures (e.g., hierarchical, peer-to-peer, clearing house) - service relationships between domain (the interdomain security mechanisms are negotiated at the level of service relationships) - static and dynamic provisioning of address information - address resolution - usage information exchange - authorization of calls Regarding your question about usage information, see the descriptions of the UsageSpec (1.8.2.4.5) and Pricing Information (1.8.2.3.2) structures, and the UsageRequest (1.8.2.25) and UsageIndication (1.8.2.28) messages (and the related confirmation and rejection messages) for more information. Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867 Greg Herlein <gherlein(a)HERLEIN.COM> on 03/03/2000 03:39:00 PM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Michael Fortinsky) Subject: H.225 Annex G H.225 Annex G does not seem to have any meat - is it *just* a border information exchange mechanism, or is it intended to provide EDI the way OSP does (ie, exchanging usage information)? >From my review, this annex looks like it does not provide any AAA functionality between administrative domains... though it does discuss address resolution. I'm looking at: http://standard.pictel.com/ftp/avc-site/9905_San/H.225.0_Annex_G_990528.zip Am I missing something, or is that all Annex G is supposed to do? Greg /************************************************************** Greg Herlein gherlein(a)herlein.com ***************************************************************/

1 0

Re: FYI - SIP-H.323 Interworking BOF
by Joon Maeng 04 Mar '00

04 Mar '00

Roy, you your are right. It is focused on the SIP and H.323 interworking. I attached the tentative agenda for the BOF. Depending on the speakers we identify, the agenda may inlcude some presenters but the main focus will not be modified. Regards, Joon ------------------------------------------------------------------------ BOF: SIP and H.323 Interworking (sip323) Area: Transport Time requested: one 1 hour slot Chairs: Joon Maeng <joon_maeng(a)vtel.com> Dave Walker <drwalker(a)ss8networks.com> Description: There are two competing standards in the industry for establishing and managing real-time interactive media communications over IP. One is the proposed IETF standard, Session Initiation Protocol (RFC 2543), and the other is the ITU recommendation, H.323. Although they use the same protocol (RTP) for media streaming, they cannot establish calls between them. In the absence of any formal interoperability standards, many vendors are beginning to develop proprietary application gateways for interworking between SIP and H.323. In order to provide interoperability between the two standards, it is urgent to define a common interworking specifications for the industry. The recognition of the need for this interworking specification has lead to calls for its development from both manufacturers and service providers, individually and through industry consortia (such as IMTC) and other bodies concerned with interoperability (such as ETSI). In this BOF, we are going to discuss SIP and H.323 interworking issues, execution plans and the scope of the work. Agenda: - Do we need SIP-H.323 interworking? - Coordination with other groups? - Scope of interworking - Outcome of the work? - Suggestions? Helpful reading: - draft-singh-sip-h323-00.txt - SIP: Session Initiation Protocol (RFC 2543) - SDP: Session Description Protocol (RFC 2327) - ITU recommendations: H.323, H.225.0, H.245 > -----Original Message----- > From: Roy, Radhika R, ALARC [mailto:rrroy@att.com] > Sent: Friday, March 03, 2000 3:12 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > Hi, Everyone: > > It appears that BOF is focused only on SIP-H.323 Interworking (not > H.323-Internet Interworking as titled by Orit). I guess that > Joon and Dave > will clarify this better. > > Best regards, > Radhika R. Roy > AT&T > > > -----Original Message----- > > From: Orit Levin [SMTP:orit@radvision.com] > > Sent: Friday, March 03, 2000 3:57 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: FYI - SIP-H.323 Interworking BOF > > > > Great! > > I am attaching the revised so far TOR. Please, send your comments. > > Hope you will find it useful in Australia. > > Best regards, > > Orit Levin > > RADVision Inc. > > 575 Corporate Drive Suite 420 > > Mahwah, NJ 07430 > > Tel: 1 201 529 4300 (230) > > Fax: 1 201 529 3516 > > www.radvision.com > > orit(a)radvision.com > > -----Original Message----- > > From: Joon Maeng <joon_maeng(a)VTEL.COM> > > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > > Date: Thursday, March 02, 2000 8:18 PM > > Subject: FYI - SIP-H.323 Interworking BOF > > > > > > >Hi folks. There will be a SIP-H.323 Interworking BOF at > the IETF meeting > > in > > >Australia. Dave Walker with SS8 Networks and I will chair > the BOF. You > > can > > >find the agenda at http://www.ietf.org/meetings/IETF-47.html when IETF > posts > >agendas. > >Regards, > >Joon << File: H323-Internet.zip >>

1 0

Re: FYI - SIP-H.323 Interworking BOF
by Roy, Radhika R, ALARC 03 Mar '00

03 Mar '00

Hi, Everyone: It appears that BOF is focused only on SIP-H.323 Interworking (not H.323-Internet Interworking as titled by Orit). I guess that Joon and Dave will clarify this better. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Orit Levin [SMTP:orit@radvision.com] > Sent: Friday, March 03, 2000 3:57 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: FYI - SIP-H.323 Interworking BOF > > Great! > I am attaching the revised so far TOR. Please, send your comments. > Hope you will find it useful in Australia. > Best regards, > Orit Levin > RADVision Inc. > 575 Corporate Drive Suite 420 > Mahwah, NJ 07430 > Tel: 1 201 529 4300 (230) > Fax: 1 201 529 3516 > www.radvision.com > orit(a)radvision.com > -----Original Message----- > From: Joon Maeng <joon_maeng(a)VTEL.COM> > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > Date: Thursday, March 02, 2000 8:18 PM > Subject: FYI - SIP-H.323 Interworking BOF > > > >Hi folks. There will be a SIP-H.323 Interworking BOF at the IETF meeting > in > >Australia. Dave Walker with SS8 Networks and I will chair the BOF. You > can > >find the agenda at http://www.ietf.org/meetings/IETF-47.html when IETF > posts > >agendas. > >Regards, > >Joon << File: H323-Internet.zip >>

1 0

Re: FYI - SIP-H.323 Interworking BOF
by Orit Levin 03 Mar '00

03 Mar '00

Great! I am attaching the revised so far TOR. Please, send your comments. Hope you will find it useful in Australia. Best regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: Joon Maeng <joon_maeng(a)VTEL.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Thursday, March 02, 2000 8:18 PM Subject: FYI - SIP-H.323 Interworking BOF >Hi folks. There will be a SIP-H.323 Interworking BOF at the IETF meeting in >Australia. Dave Walker with SS8 Networks and I will chair the BOF. You can >find the agenda at http://www.ietf.org/meetings/IETF-47.html when IETF posts >agendas. >Regards, >Joon

1 0

Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
by Matt Holdrege 03 Mar '00

03 Mar '00

I agree with narrowing of options, but market reality means the MGC's in most cases must support both. That's what I was referring to. At 01:21 PM 3/3/00 -0500, Rosen, Brian wrote: >Matt > >The protocol states MGCs SHOULD support both. That is not >a requirement. > >The purpose of a profile is to narrow down the breadth that the >protocol specifies so that you can plug an MG into an MGC and you >KNOW that they will play. This is generally NOT the case with >a random MG plugging into a random MGC - there are lots and lots >of things that would make them not compatible, and still both >be conformant to the protocol. > >For each and every option possible in the protocol, a well defined >profile should specify a minimum requirement. A conformant >device should be able to go above the minimum. This means in >every profile, a choice will be made on encoding. If this is >not done, then a customer cannot tell by comparing the profile >of an MG whether it will be compatible with his MGC. He should >absolutely be able to do this. > >In this case, if an MGC advertises that it conforms to the IPPhone >profile, but does not support text encoding, it is not out >of compliance with either the protocol or the profile. If you >try to plug a binary-only IPPhone into such a system, it won't >work. That is, in my opinion, unacceptable. > >I will even go so far as to say that the minimum is also the >preferred - even if the device can do more, the point of a profile >is to specify a set of option choices that will allow 100% >compatibility. If you have a device that REQUIRES some profile x >PLUS some feature y, then it would be better to define a new >profile as being an extension of x to include y. > >Brian > > > -----Original Message----- > > From: Matt Holdrege [mailto:holdrege@lucent.com] > > Sent: Friday, March 03, 2000 12:56 PM > > To: Rosen, Brian > > Cc: ITU-SG16(a)mailbag.cps.INTEL.COM > > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > > > > If MGC's must support both text and binary, what does it hurt > > to allow IP > > phones to do either? > >

1 0

Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
by Rosen, Brian 03 Mar '00

03 Mar '00

Matt The protocol states MGCs SHOULD support both. That is not a requirement. The purpose of a profile is to narrow down the breadth that the protocol specifies so that you can plug an MG into an MGC and you KNOW that they will play. This is generally NOT the case with a random MG plugging into a random MGC - there are lots and lots of things that would make them not compatible, and still both be conformant to the protocol. For each and every option possible in the protocol, a well defined profile should specify a minimum requirement. A conformant device should be able to go above the minimum. This means in every profile, a choice will be made on encoding. If this is not done, then a customer cannot tell by comparing the profile of an MG whether it will be compatible with his MGC. He should absolutely be able to do this. In this case, if an MGC advertises that it conforms to the IPPhone profile, but does not support text encoding, it is not out of compliance with either the protocol or the profile. If you try to plug a binary-only IPPhone into such a system, it won't work. That is, in my opinion, unacceptable. I will even go so far as to say that the minimum is also the preferred - even if the device can do more, the point of a profile is to specify a set of option choices that will allow 100% compatibility. If you have a device that REQUIRES some profile x PLUS some feature y, then it would be better to define a new profile as being an extension of x to include y. Brian > -----Original Message----- > From: Matt Holdrege [mailto:holdrege@lucent.com] > Sent: Friday, March 03, 2000 12:56 PM > To: Rosen, Brian > Cc: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > If MGC's must support both text and binary, what does it hurt > to allow IP > phones to do either? >

1 0

Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
by Matt Holdrege 03 Mar '00

03 Mar '00

If MGC's must support both text and binary, what does it hurt to allow IP phones to do either?

1 0