Draft Status Update

[Paul E. Jones]

Bob,

I suppose it could, though I have not heard anybody focusing on multimedia
in SIP.  There are certainly a lot of missing pieces on that side for doing
that.  They could do audio and video at the very least.

The folks I have heard from have been asking for a codepoint to advertise
that the gateway is an H.323 to SIP gateway.  The question is simply how to
signal that?  There's plenty of options, but we should select the one that
makes the most sense.

Paul

----- Original Message -----
From: "Callaghan, Robert" <Robert.Callaghan at icn.siemens.com>
To: "'Paul E. Jones'" <paulej at packetizer.com>;
<ITU-SG16 at mailbag.cps.intel.com>
Sent: Friday, December 01, 2000 3:49 AM
Subject: RE: Draft Status Update


> Paul,
>
> Actually a gateway should advertise "voice" if it only support voice.
> Advertising "h323" means that the full multimedia suite of H.323 is
> supported.  What is the intent of the H.323 to SIP gateway?  Will it
> interwork the full multimedia suite?
>
> Bob
>
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej at packetizer.com]
> Sent: Thursday, November 30, 2000 6:33 PM
> To: Callaghan, Robert; ITU-SG16 at mailbag.cps.intel.com
> Subject: Re: Draft Status Update
>
>
> Bob,
>
> The very fact that SIP is sitting on the back side of this H.323 device
was
> one reason I never pursued trying to add a "sip" codepoint, per se.
Adding
> "sip" as a codepoint might suggest that the SIP devices are doing RAS and
I
> know that would send shivers through the SIP community :-)
>
> Perhaps the right approach is to say that "h323" is the right choice and
we
> should clarify in H.225.0 that this codepoint is used to indicate an H.323
> GW that reaches other IP-based protocols.
>
> I think we need to say something, because this issue comes up from time to
> time.  People want to feel comfortable that when they register a gateway
and
> provide SIP interworking that they advertise the right protocol to the GK.
> I don't see any reason why the GK should care whether the GW is actually
> using SIP, BICC, or H.323 on the back side.
>
> Is there a technical reason why should or should not allow "h323" to be
used
> as I suggest above?  I think we're in agreement that this does, indeed,
act
> like nothing more than an H.323 firewall and if it advertises the ability
to
> reach the desired destination-- I suppose that's all we need to care
about.
>
> Paul
>
> ----- Original Message -----
> From: "Callaghan, Robert" <Robert.Callaghan at icn.siemens.com>
> To: "'Paul E. Jones'" <paulej at packetizer.com>;
> <ITU-SG16 at mailbag.cps.intel.com>
> Sent: Thursday, November 30, 2000 7:37 AM
> Subject: RE: Draft Status Update
>
>
> > Paul,
> >
> > Based on the rule that the SIP-H.323 gateway appears to the endpoints as
> an
> > H.323 firewall, then this will work.  If there ever is any difference,
> then
> > there is a problem
> >
> > I prefer to keep the "h323" designation.
> >
> > Bob
> >
> > -----Original Message-----
> > From: Paul E. Jones [mailto:paulej at packetizer.com]
> > Sent: Wednesday, November 29, 2000 8:33 PM
> > To: Callaghan, Robert; ITU-SG16 at mailbag.cps.intel.com
> > Subject: Re: Draft Status Update
> >
> >
> > Bob,
> >
> > I was not suggesting that we use the h323-ID field any differently-- it
> was
> > the "h323" field inside the supportedProtocols choice.  It is used to
> > indicate a gateway that gateways to H.323 devices.  However, it could
> serve
> > just as well to say it gateways to any IP telephony protocol.  That's
why
> I
> > suggested we call it "ipgw".
> >
> > Whether we do that or add a "sip" field makes no difference to me, but
the
> > latter option may take 2 years.
> >
> > Paul
> >
> > ----- Original Message -----
> > From: "Callaghan, Robert" <Robert.Callaghan at icn.siemens.com>
> > To: "'Paul E. Jones'" <paulej at PACKETIZER.COM>;
> > <ITU-SG16 at mailbag.cps.intel.com>
> > Sent: Wednesday, November 29, 2000 4:18 AM
> > Subject: RE: Draft Status Update
> >
> >
> > > Paul,
> > >
> > > I thought that the object of the IWF is to make the mixing of H.323
> > > terminals and SIP terminals transparent.
> > >
> > > However, I could see supporting SIP: URLs in the H.323 URL field along
> > with
> > > the H.323 URL.  This would be possible under the URL rules for
H.323v4.
> I
> > > would also expect SIP terminals to support the H.323 URL.
> > >
> > > The does not solve the problem of true E.164 Ids or the TEL: URL.  A
> true
> > > E.164 Id does not allow for a service prefix.  In that this is the
> normal
> > Id
> > > for voice calls, it must have a solution.  An added problem is "Number
> > > Portability" which tends to kill number grouping.
> > >
> > > I do not accept the concept of hidden usages of any field.  Therefor I
> do
> > > not support the use of the H.323ID field having a special format that
> > > indicates a SIP connection.  The H.323ID field should remain a free
> format
> > > string.
> > >
> > > As it was stated, the gateway identifieds as having H.323 protocol is
> used
> > > by firewalls doing H.323-H.323.  Also voice indicates any gateway
> support
> > > voice only connections.  These should be mis-used.  Adding a new
> protocol
> > > type for a gateway would have to wait.
> > >
> > > Bob
> > >
> > > -----Original Message-----
> > > From: Paul E. Jones [mailto:paulej at PACKETIZER.COM]
> > > Sent: Tuesday, November 28, 2000 12:08 AM
> > > To: ITU-SG16 at mailbag.cps.intel.com
> > > Subject: Re: Draft Status Update
> > >
> > >
> > > Charles,
> > >
> > > I have discussed that idea with people before.
> > >
> > > I'm certainly open to the idea of adding a "sip" codepoint.  However,
> > since
> > > H.323v4 was just approved, we'd have to wait for 2 years to get it in
> > there.
> > > We might be able to persuade folks to use the "h323" field for IP GWs
> and
> > > document that in the H.323 Implementers Guide-- perhaps even changing
> the
> > > name in v5 to "ipgw".
> > >
> > > Paul
> >
> >
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com