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@packetizer.com] Sent: Wednesday, November 29, 2000 8:33 PM To: Callaghan, Robert; ITU-SG16@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@icn.siemens.com To: "'Paul E. Jones'" paulej@PACKETIZER.COM; ITU-SG16@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@PACKETIZER.COM] Sent: Tuesday, November 28, 2000 12:08 AM To: ITU-SG16@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
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@icn.siemens.com To: "'Paul E. Jones'" paulej@packetizer.com; ITU-SG16@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@packetizer.com] Sent: Wednesday, November 29, 2000 8:33 PM To: Callaghan, Robert; ITU-SG16@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@icn.siemens.com To: "'Paul E. Jones'" paulej@PACKETIZER.COM; ITU-SG16@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@PACKETIZER.COM] Sent: Tuesday, November 28, 2000 12:08 AM To: ITU-SG16@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@mailbag.intel.com
participants (2)
-
Callaghan, Robert -
Paul E. Jones