New subject: Draft Status Update

29 Nov 2000

      ...
Paul,
The "sip" option shouild be used by an H.323-SIP gateway if such a
code-point was available ( following the example you gave, the
"h323"option
would not be *correct* for an H.323-SIP gw ).  In light of this, should
there be a code-point  ("sip") for SIP (it is no longer a nonStandard
protocol)in H.323v5?
charles
-----Original Message-----
From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Monday, November 27, 2000 7:56 PM
To: Agboh, Charles; 'Wong, Walter'; 'Roy, Radhika R, ALCOO'; Wang, Dave;
VPalawat@opuswave.com; kns10@cs.columbia.edu
Cc: joon_maeng@vtel.com; hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com; David Daiker
Subject: Re: Draft Status Update
Charles,
"voice" is supposed to be used by voice gateways.
"h323" is supposed to be used by H.323-H.323 GWs (proxies).
BTW, it should be noted that "supportedPrefixes" does *not* indicate what
E.164 prefixes a gateway can reach.  some implementers have interpreted it
that way and others have interpreted it to indicate "service prefixes",
such
as dialing "9" to reach an outside line.  The latter definition is the
correct interpretation.
H.323v4 now has fields that are there specifically for registering E.164
address ranges.
Paul
----- Original Message -----
From: "Agboh, Charles" <Charles.Agboh@gts.com>
To: "'Wong, Walter'" <wwong@nuera.com>; "'Roy, Radhika R, ALCOO'"
<rrroy@att.com>; "Wang, Dave" <dwang@nuera.com>; <VPalawat@opuswave.com>;
<kns10@cs.columbia.edu>
Cc: <joon_maeng@vtel.com>; <hemantag@globespan.net>;
<schulzrinne@cs.columbia.edu>; <alan.johnston@wcom.com>; "David Daiker"
<ddaiker@cisco.com>; <paulej@cisco.com>
Sent: Friday, November 24, 2000 12:10 PM
Subject: RE: Draft Status Update
...
Hi,
A comment about
RegistrationRequest.terminalType.gateway.protocol.h323.supportPrefixes
IE.
I saw an H.323-ISDN/voice gateway from Cisco (AS5300) that uses the
RegistrationRequest.terminalType.gateway.protocol.voice.supportPrefixes
IE
instead of
RegistrationRequest.terminalType.gateway.protocol.h323.supportPrefixes
IE
to
define the supported prefixes.
Dave, can you comment on this?
regards,
charles
-----Original Message-----
From: Wong, Walter [mailto:wwong@nuera.com]
Sent: Wednesday, November 22, 2000 3:13 AM
To: 'Roy, Radhika R, ALCOO'; Agboh, Charles; Wong, Walter; Wong, Walter;
Wang, Dave; VPalawat@opuswave.com; kns10@cs.columbia.edu
Cc: joon_maeng@vtel.com; hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com; David Daiker
Subject: RE: Draft Status Update
Hi Roy, Charles, and all,
Thanks Charles for pointing out the use of supportedPrefix field.  I
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

----- Original Message -----
From: "Agboh, Charles" <Charles.Agboh@gts.com>
To: "'Paul E. Jones'" <paulej@packetizer.com>; "'Wong, Walter'"
<wwong@nuera.com>; "'Roy, Radhika R, ALCOO'" <rrroy@att.com>; "Wang, Dave"
<dwang@nuera.com>; <VPalawat@opuswave.com>; <kns10@cs.columbia.edu>
Cc: <joon_maeng@vtel.com>; <hemantag@globespan.net>;
<schulzrinne@cs.columbia.edu>; <alan.johnston@wcom.com>; "David Daiker"
<ddaiker@cisco.com>; <ITU-SG16@mailbag.cps.intel.com>
Sent: Monday, November 27, 2000 2:09 PM
Subject: RE: Draft Status Update

think
...
...
the IWF can use
...
...
x.e164 field of the RRQ to register an e164 prefix.  This way, it's not
non-standard any more.  Using "SIP" as the non-standard
supportedProtocol
has some concerns.  a) It's non-standard, b) The H.323 side will know
...
...
IWF is not a usual or "genuine" H.323 GW.  This may violate the
requirement
that the IWF should make both side unaware of the protocol difference.
Charles, do you know if a prefix works for other type of aliases besides
e.164?  For example, what if we put ...supportedPrefix.prefix.url-id in
the
RRQ?
As far as standard is concerned, we should leave room for vendors to
come
up
with their own implementation of how this problem is solved.  My
...
...
solution is just one of the possible ways to get around the registration
issues.  We shouldn't put that as a hard requirement for an IWF to have
table lookup function.  My suggestion is to put this as a recommendation
and
use the word "MAY", not "MUST".
-Walter
-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com]
Sent: Tuesday, November 21, 2000 9:23 AM
To: Agboh, Charles; Wong, Walter; Wong, Walter; Wang, Dave;
VPalawat@opuswave.com; kns10@cs.columbia.edu
Cc: joon_maeng@vtel.com; hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com; David Daiker
Subject: RE: Draft Status Update
Hi, Charles, Walter and All:
The non-standard protocol field may provide to do this. The puzzle is
...
...
it is still a "non-standard" and each vendor may implement differently.
It appears that our SIP-H.323 Interworking standard likes to make this
"non-standard" scheme as the standard one.
Is that acceptable? Comments?
Best regards,
Radhika
-----Original Message-----
From: Agboh, Charles [mailto:Charles.Agboh@gts.com]
Sent: Monday, November 20, 2000 4:54 AM
To: Roy, Radhika R, ALCOO; Wong, Walter; Wong, Walter; Wang, Dave;
VPalawat@opuswave.com; kns10@cs.columbia.edu
Cc: joon_maeng@vtel.com; hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com; David Daiker
Subject: RE: Draft Status Update
Hi Roy, Walter and all:
Walter's proposed solution is sound for H.323 v2 compatibility.     In
...
...
RegistrationRequest.terminalType.gateway.protocol.h323 |
[nonstandardprotocol].supportPrefixes.prefix.e164 field of the RRQ the
IWF
can register an e164 prefix.  H.323 gateways register their prefixes
using
this field.   The supported protocols in this example should not be h323
(?), instead, it should be "sip"  for the IWF.   The nonstandardprotocol
field will allow the IWF to register "sip" has the supported protocol.
The "prefix" that the IWF registers should be well-known.
regards,
charles
-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com]
Sent: Saturday, November 18, 2000 8:52 AM
To: Wong, Walter; Agboh, Charles; Wong, Walter; Wang, Dave;
VPalawat@opuswave.com; kns10@cs.columbia.edu
Cc: joon_maeng@vtel.com; hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com; David Daiker
Subject: RE: Draft Status Update
Hi, Walter:
Yes, your proposal is a good one considering all the options that we
have.
In fact, the grouping of the addresses shall be the main aspect of the
registration by the IWF in any situation.
For E.164, it is clear. Let all members provide comments for grouping of
the
SIP addresses as proposed by you. In fact, we are assuming that the IWF
will
have the capabilities for the local address translation using the table
look-up, and grouping of the SIP-side address may be another feature.
The
question is: How far we can make this acceptable from the standard point
of
view?
Best regards,
Radhika
-----Original Message-----
From: Wong, Walter [mailto:wwong@nuera.com]
Sent: Friday, November 17, 2000 2:48 PM
To: Roy, Radhika R, ALCOO; Agboh, Charles; Wong, Walter; Wang, Dave;
VPalawat@opuswave.com; kns10@cs.columbia.edu
Cc: joon_maeng@vtel.com; hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com; David Daiker
Subject: RE: Draft Status Update
Hi Radhika, Charles and all,
Regarding the 2 solutions we have discussed, both have backward
compatility
problems.  H.323 v4 case is obvious.  The lightweight RRQ with KeepAlive
solution also require modification of current GK behavior by
implementing
the new recommendation.  So the IWF would still have problem when
working
with existing GK's out there that did not implement the new
recommendation.
So as far as backward compatibility is concerned, each of the 2
solutions
don't have advantage over the other.  Because of the tricky nature of
...
...
lightweight RRQ approach, I tend to agree working towards H.323 V4 may
be
a
better way to go.
But we still need to address the issue when we integrate the IWF into an
existing H.323 v2 GK domain.  One possible way is to pre-register all
SIP
endpoints to the GK by static GK configuration.  This is not a good
solution
because of the static nature of the approach.  It loses the dynamic
...
...
reqister and unregister.  It also require reconfiguring the GK whenever
there is a change on the SIP side.
Another thinking that I have is to put some address mapping intellegence
in
the IWF.  The IWF maps a SIP url to a specific e.164 number.  The good
of
thing
...
about e.164 number is we can group the numbers with a prefix.  For
example,
in the GK domain, we can assign a number prefix for the SIP network
...
...
on the other side of the IWF.  Then pre-register all numbers with this
prefix (i.e. any number with area code 123) by static GK configuration.
This way, any destination number with the prefix 123 will get routed by
the
GK to the IWF.  The IWF then maps the number to a SIP url when
connecting
the call to the SIP side.  From the SIP side, the IWF assigns a number
with
prefix 123 for each SIP endpoint that registers with the IWF and keeps
...
...
assignment in a local map.  When a SIP call is going through the IWF to
the
H323 side, the IWF uses this number from the local map with prefix 123
as
the source alias when connecting the call with the GK.
The advantage of this approach is it doesn't require registering of all
the
SIP endpoints individually.  Instead, register them as a group.
This approach would work the best if we can find a way to do
registration
with a group of numbers using some range or wildcard notion in the RRQ.
It
would solve the problem of statically configuring the GK and allow for
dynamic registeration.  Unfortunately I wasn't able to find such a way
from
the current H.323 documentation.  Does anyone aware of any such way to
do
group registration without specifying individual aliases in the RRQ?
Thanks,
-Walter
-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com]
Sent: Thursday, November 16, 2000 11:29 PM
To: Agboh, Charles; 'Wong, Walter'; Wang, Dave; VPalawat@opuswave.com;
kns10@cs.columbia.edu
Cc: joon_maeng@vtel.com; hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com; David Daiker
Subject: RE: Draft Status Update
Hi, Charles and Walter:
The solution is in sight to proceed with standardization form H.323
version
2 to H.323 Version 4 as quickly as possible keeping in mind that we have
problems now.
Radhika
-----Original Message-----
From: Agboh, Charles [mailto:Charles.Agboh@gts.com]
Sent: Thursday, November 16, 2000 6:06 AM
To: 'Wong, Walter'; Roy, Radhika R, ALCOO; Wang, Dave;
VPalawat@opuswave.com; kns10@cs.columbia.edu
Cc: joon_maeng@vtel.com; hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com; David Daiker
Subject: RE: Draft Status Update
Hi Walter,
You are right, use of lightweight RRQ for additive registration is
...
...
The keyword is "SHOULD".  The recommeded behaivior for a GK is to ignore
the
terminalAlias field in the lightweight RRQ.  So what can we do to allow
the
SIP EP to register its aliase via the IWF without using non-standard
"tips
and tricks".
- Base the I-D on H.323 v4:   Backward compatibility problem (not
really
an option)
    - Recommend that the GK SHOULD NOT replace new alias address (for
...
...
same transport address) and SHOULD NOT ignore the terminalAlias fields
in
a
lightweight RRQ for a given  endpointIdentifier when communicating with
the
IWF or any other type of gateway.  This will be backward compatible with
H.323v2 (as you can see below:  ".....should...." ).
*Section 7.2.2/H.323v2
                -------------------------------
                 " If the Gatekeeper receives an RRQ having the same
Transport Address as a previous RRQ and a different alias address, it
should
replace the translation table entries."
*Section  7.9.1/H.225v2
                 -------------------------------
"A gatekeeper in receipt of RRQ with a keepAlive field set to TRUE
should ignore fields other than endpointIdentifier,
gatekeeperIdentifier,
tokens, and timeToLive."
comments or suggestions?
regards,
charles
-----Original Message-----
From: Wong, Walter [mailto:wwong@nuera.com]
Sent: Wednesday, November 15, 2000 7:48 PM
To: Agboh, Charles; 'Roy, Radhika R, ALCOO'; Wang, Dave;
VPalawat@opuswave.com; kns10@cs.columbia.edu
Cc: joon_maeng@vtel.com; hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com; Wong, Walter
Subject: RE: Draft Status Update
Hi Charles,
You right, one RRQ may not be able to carry all aliases because of the
size
limitation of the packet.  So we have to find a way for the IWF to
register
all the SIP endpoints in seperate RRQs.
The use of lightweight RRQ is tricky and need more thought.  When TTL
expires, an RRQ should contain the "KeepAlive" field set to TRUE.  Here
is
the description of KeepAlive from section 7.9.1 of H225v3:
"
keepAlive - If set to TRUE indicates that the endpoint has sent this RRQ
as
a "keep alive". An endpoint can send a lightweight RRQ consisting of
only
rasAddress, keepAlive, endpointIdentifier, gatekeeperIdentifier, tokens,
and
timeToLive. A gatekeeper in receipt of RRQ with a keepAlive field set to
TRUE should ignore fields other than endpointIdentifier,
gatekeeperIdentifier, tokens, and timeToLive. The rasAddress in a
lightweight RRQ shall only be used by a gatekeeper as the destination
for
an
RRJ when the endpoint is not registered.
"
The tricky part about this is: when KeepAlive is TRUE, the GK should
ignore
the Terminal Alias field (3rd sentense above).  However, if we set the
KeepAlive to FALSE, the GK may treat it as a new RRQ and thus,
overwrites
the previously registerred aliases.  This GK behavior may be vendor
implementation dependent.  Apparently, the GK I did the experiment with
was
doing it this way.
The additive registration feature in H323 V4 seems to be a promissing
solution.  However, it brings up a backward compatibility issue when the
IWF
is talking to a H323 V2 GK.
-Walter
-----Original Message-----
From: Agboh, Charles [mailto:Charles.Agboh@gts.com]
Sent: Wednesday, November 15, 2000 7:48 AM
To: 'Roy, Radhika R, ALCOO'; Wang, Dave; VPalawat@opuswave.com;
kns10@cs.columbia.edu
Cc: joon_maeng@vtel.com; hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com; Wong, Walter
Subject: RE: Draft Status Update
Hi,
The problem with registering multiple alias addresses with a GK was
...
...
the size limitation of a UDP packet just prevented that from happening.
A
solution around  this limitation is to use the additive registration
feature
in H.323 v4.   Unfortunately our current I-D is based on H.323V2.  An
interim solution may be the use of the lighweight RRQ.   With this
approache, each time an RRQ TTL expires the IWF may send more aliases to
the
GK (should fill the terminal alias field).     The problem with this
solution is that the RRQ is no longer *lightweight*.   The second
RegistrationRequest.terminalType.gateway.protocol.h323.supportPrefixes.prefi
the
proposed
that
the
the
power
that's
the
tricky.
the
this:
problem
...
...
which walter mentioned is that the GK overwrites previous terminalAlias
(It
shoudn't since the terminal alias's are different while the transport
address remains the same).
Best regards,
charles
-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com]
Sent: Wednesday, November 15, 2000 7:38 AM
To: Wang, Dave; VPalawat@opuswave.com; Agboh, Charles;
kns10@cs.columbia.edu
Cc: joon_maeng@vtel.com; hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com; Wong, Walter
Subject: RE: Draft Status Update
Hi, Walter and All:
I guess that you may be right.
Can we change the behavior like this: Can we not say that the IWF sends
all
aliases together each time it sends the RRQ?
It may be a crude method. What else could we do? The other solution may
be
to make GK and IWF collocated. We may not like to do this as well.
All members are requested to provide their comments as well.
Best regards,
Radhika
-----Original Message-----
From: Wang, Dave [mailto:dwang@nuera.com]
Sent: Tuesday, November 14, 2000 3:33 AM
To: VPalawat@opuswave.com; Roy, Radhika R, ALCOO; Charles.Agboh@gts.com;
kns10@cs.columbia.edu
Cc: joon_maeng@vtel.com; hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com; dwang@nuera.com;
Wong, Walter
Subject: RE: Draft Status Update
Hi All,
Here is some comments from my colleague Walter Wong, who is our expert
on
SIP/H.323 IWF. You may want to replace me by Walter in the e-mail list,
and
consider recruiting him in this work and drop me off it.
David Wang
...
-----Original Message-----
From: Wong, Walter
Sent: Monday, November 13, 2000 7:29 PM
To: Wang, Dave
Subject: RE: Draft Status Update
Hi Dave,
The registration scheme specified here for registering with
GK my not work.  The IWF may not be able to send seperate RRQ
for each SIP end point.  Here is the description from
H.225v3, section 7.9.1 on RRQ:
"terminalAlias -This optional value is a list of alias
addresses, by which other terminals may identify this
terminal. If the terminalAlias is null, or an E.164 address
is not present, an E.164 address may be assigned by the
gatekeeper, and included in the RCF. If an email-ID is
available for the endpoint, it should be registered. Note
that multiple alias addresses may refer to the same transport
addresses. All of the endpoint's aliases shall be included in
each RRQ."
The scheme seems to be violating the last sentense.
I've also done some experiment with the Cisco 3600 GK.  If I
send RRQ with 8000001 then another RRQ with 8000002 from the
same GW, the GK loses the 8000001 as soon as the RRQ for
8000002 is received.
We have to find another way to get around this unless we can
change the GK behavior.  Packing all individual endpoint
aliases in 1 RRQ is not a good solution because it's limited
by the size of the RRQ.  I have not been successful in
finding a way to specify a range of aliases or use wildcard
in the RRQ.  Although not flexible, statically configuring
the GK may be a workable solution.
-Walter
...
-----Original Message-----
From: VPalawat@opuswave.com [mailto:VPalawat@opuswave.com]
Sent: Monday, November 13, 2000 1:33 PM
To: rrroy@att.com; VPalawat@opuswave.com; Charles.Agboh@gts.com;
kns10@cs.columbia.edu
Cc: joon_maeng@vtel.com; hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com; dwang@nuera.com
Subject: RE: Draft Status Update
Hi All,
A quick update on the draft status:
* Last minute changes and some error corrections to Call Flow
diagrams.
* More additions to other sections are under progress.
* Draft formatting is under progress.
Please let me know if you have any comments/suggestions on my
approach/opinion.
Best Regards
Vipin
-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com]
Sent: Sunday, November 12, 2000 10:53 AM
To: VPalawat@opuswave.com; Charles.Agboh@gts.com;
kns10@cs.columbia.edu
Cc: joon_maeng@vtel.com; hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com; dwang@nuera.com
Subject: RE: Draft Status Update
<< File: Registration_v3.txt >> << File:
Requirements.txt
...
...
Hi, Vipin and All:
I am enclosing two files for the following two sections:
1. Registration and Address Resolution (Version 3)
2. SIP-H.323 Interworking Requirements
For address resolution, I have an issue as follows:
Does the IWF will send the response (200 OK) to
the SIP EP
after receiving
the REGISTER message because we do not assume
that IWF may
act as the
register server?
Based on comments provided earlier, I have
modified the last
flow diagram
assuming that the IWF and the H.323 GK are NOT
co-located.
Still, I have
been able to use the OPTIONS message to resolve the
H.323-side addresses.
However, I have not been able to use the
OPTIONS message for
resolving the
SIP-side addresses if the ARQ/LRQ messages come from the
H.323-side unless
IWF and GK are co-located.
Can anyone help to find examples for this
scenario using the
OPTIONS
message?
The OPTIONS message is an extremely useful one and H.323
does NOT have any
equivalent one. (It silently provides all the
capabilities
of the SIP
entities without going through needless
negotiations like
H.245 messages.)
I am yet to show all fields of all messages in
the message
flows. Hope to
refine those later.
For the SIP-H.323 Interworking Requirements
section, I also
like to have
your comments.
Best regards,
Radhika
PS: I have apprised the ITU-T SG16 Q.13/16
meeting delegates
about the
progress of our SIP-H.323 Interworking works in
the IETF.
-----Original Message-----
From: VPalawat@opuswave.com
[mailto:VPalawat@opuswave.com]
Sent: Friday, November 10, 2000 2:45 PM
To: VPalawat@opuswave.com; Charles.Agboh@gts.com;
kns10@cs.columbia.edu
Cc: joon_maeng@vtel.com; hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com;
dwang@nuera.com;
Roy, Radhika R, ALCOO
Subject: RE: Draft Status Update
Hi All,
Here is a quick update on the status of the draft.
* Detailed description of calls  along
with message
details in call
flow diagrams is complete.
* Basic message handling Section is
nearly complete.
Following sections are still under progress:
* State m/c diagram. Lot of work is there.
I would like to have your opinion on the state
of the draft.
I also want to know that if in case we were unable to
complete the state m/c
on time, then
Can we include it in the "TO DO" list and later
we will add
it into the next
release of the same draft.
This is because I don't want to put everything
in a rush.
This will impact
the quality of the document.
We have already written the draft in a short
time, so I feel
if we were
unable to complete that section,
Then it is better to put it in the "TO DO" list
and better
concentrate on
the review of the existing stuff.
I would like to have your opinions on this.
Please let me know if you have any
comments/suggestions on
my
approach/opinion.
Best Regards
Vipin
-----Original Message-----
From: Palawat, Vipin
Sent: Thursday, November 09,
2000 10:02 AM
To: 'Agboh, Charles'; 'Kundan Singh'
Cc: Palawat, Vipin;
joon_maeng@vtel.com;
hemantag@globespan.net; schulzrinne@cs.columbia.edu;
alan.johnston@wcom.com;
dwang@nuera.com; rrroy@att.com
Subject: Draft Status Update
Hi All,
Here is a quick update on the
status of the
draft.
Following section were almost complete:
* Detailed description and call message details in
call flow diagrams.
Following sections are
still under
progress:
* Basic Call Handling.
* State m/c
Please let me know if you have any
comments/suggestions on
my approach/opinion.
Best Regards
Vipin
-----Original
Message-----
From: Agboh, Charles
[mailto:Charles.Agboh@gts.com]
Sent:
Wednesday, November
08, 2000 3:05 PM
To: 'Kundan Singh'
Cc:
'VPalawat@opuswave.com';
ddaiker@cisco.com; joon_maeng@vtel.com;
hemantag@globespan.net;
schulzrinne@cs.columbia.edu; alan.johnston@wcom.com;
dwang@nuera.com;
rrroy@att.com
Subject:
RE: Message
Mapping:
SIP-H.323 interworking
Hi,
Can we keep Dave
(ddaiker@cisco.com) in the
discussion.
regards
charles
-----Original
Message-----
From: Kundan Singh
[mailto:kns10@cs.columbia.edu]
Sent:
Wednesday, November
08, 2000 6:57 PM
To: Agboh, Charles
Cc:
'VPalawat@opuswave.com';
ddaiker@cisco.com; joon_maeng@vtel.com;
hemantag@globespan.net;
schulzrinne@cs.columbia.edu;
alan.johnston@wcom.com;
dwang@nuera.com;
rrroy@att.com
Subject: RE: Message
Mapping: SIP-H.323
interworking
...
Are we going
to constrain
an
implementation to an algorithm for matching
SDP
capability
description ang
H.245?  I think
we should leave it open and say
that there must be at
least an
intersection and that intersection must
include G.711.
I agree that it
should be
open, however, we
can provide a
guideline for
finding such
intersection with
examples.
Secondly,
"intersection must
include G.711"
is not
acceptable, I think,
especially if the SIP
side
does not
support G.711 and
the IWF provider
is capable of doing
conversion between
G.711 (from
H.323 EP) and
some other codec
(from SIP UA).
Having G.711 always
mandatory will
eventually cause the
SIP calls
(without G.711) to
be always
rejected.
...
H.225.0/Q.931
part (not
UUIE):
I think, we can
ignore the
unnecessary
fields in
this phase and
can look at
it in the next
phase, if needed.
Some of the fields (like
Caller Number) can
be used
in IWF.
Will send more comments
soon.
Thanks and regards
Kundan
...
Can we get perspective
from vendors on
this (ie. bearer cap..)
vipin, how do
you want to
proceed?
regards,
charles
-----Original
Message-----
From:
VPalawat@opuswave.com
[mailto:VPalawat@opuswave.com]
Sent:
Wednesday, November
08, 2000 5:45 PM
To: Agboh, Charles;
ddaiker@cisco.com
Cc:
joon_maeng@vtel.com;
hemantag@globespan.net;
...
rrroy@att.com;
VPalawat@opuswave.com;
kns10@cs.columbia.edu
Subject: RE: Message
Mapping: SIP-H.323
interworking
Hi All,
A quick update on the
status of the
current draft.
* Work in
still going
on in the
following sections.
*
Description of Call
Flow diagrams.
* State m/c
* Basic Message
Handling.
As soon as
...
to all the editors.
I will keep
on updating
schulzrinne@cs.columbia.edu;
alan.johnston@wcom.com; dwang@nuera.com;
the draft comes
to a complete
and good shape, I will forward it
the status twice a
day.
...
Please let me
know if you
have any
comments/suggestions on my
...
approach/opinion.
Best Regards
Vipin
-----Original Message-----
...
From:
Agboh, Charles
[mailto:Charles.Agboh@gts.com]
Sent:
Tuesday, November
07, 2000 11:19 AM
To:
'David Daiker'
Cc:
Agboh, Charles;
joon_maeng@vtel.com;
hemantag@globespan.net;
schulzrinne@cs.columbia.edu;
alan.johnston@wcom.com;
...
dwang@nuera.com;
rrroy@att.com;
VPalawat@opuswave.com;
kns10@cs.columbia.edu
Subject:
RE: Message
Mapping: SIP-H.323 interworking
Hi David,
...
I will open
the discussion
tomorrow with my contribution
...
which is mostly
derived from
Kundan Singh's
work (Its going to be a long
...
night).   I think
it will be
difficult to come
up with something consistent
...
before the 16th
but, we will
try.
...
We welcome
your
participation in this discussion.
...
Best
regards,
...
charles,
-----Original Message-----
...
From: David
Daiker
[mailto:ddaiker@cisco.com]
...
Sent:
Tuesday, November 07,
2000 4:50 PM
To: Agboh,
Charles
...
Cc: David
Daiker
...
Subject: Re:
Message
Mapping: SIP-H.323 interworking
...
Hi Charles,
...
...
mapping
Sorry for
the late response,
I am just starting to look at
headers/parms/ies
between sip/isup/h323.
...
And quite
honestly, other
than the obvious (calling, called,
...
bearer cap,
timestamps)
I don't have
anything specific in mind.
...
Though I
will certainly
provide Cisco's perspective and
...
participate
in any
discussions.
thanks,
david
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com

RE: Draft Status Update

Callaghan, Robert

Paul E. Jones

tags

participants (2)