Draft Status Update

Paul E. Jones paulej at PACKETIZER.COM
Mon Nov 27 18:07:44 EST 2000


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


> 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 at packetizer.com]
> Sent: Monday, November 27, 2000 7:56 PM
> To: Agboh, Charles; 'Wong, Walter'; 'Roy, Radhika R, ALCOO'; Wang, Dave;
> VPalawat at opuswave.com; kns10 at cs.columbia.edu
> Cc: joon_maeng at vtel.com; hemantag at globespan.net;
> schulzrinne at cs.columbia.edu; alan.johnston at 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 at gts.com>
> To: "'Wong, Walter'" <wwong at nuera.com>; "'Roy, Radhika R, ALCOO'"
> <rrroy at att.com>; "Wang, Dave" <dwang at nuera.com>; <VPalawat at opuswave.com>;
> <kns10 at cs.columbia.edu>
> Cc: <joon_maeng at vtel.com>; <hemantag at globespan.net>;
> <schulzrinne at cs.columbia.edu>; <alan.johnston at wcom.com>; "David Daiker"
> <ddaiker at cisco.com>; <paulej at 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 at nuera.com]
> > Sent: Wednesday, November 22, 2000 3:13 AM
> > To: 'Roy, Radhika R, ALCOO'; Agboh, Charles; Wong, Walter; Wong, Walter;
> > Wang, Dave; VPalawat at opuswave.com; kns10 at cs.columbia.edu
> > Cc: joon_maeng at vtel.com; hemantag at globespan.net;
> > schulzrinne at cs.columbia.edu; alan.johnston at 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
think
> > the IWF can use
> >
>
RegistrationRequest.terminalType.gateway.protocol.h323.supportPrefixes.prefi
> > 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
the
> > 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
proposed
> > 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 at att.com]
> > Sent: Tuesday, November 21, 2000 9:23 AM
> > To: Agboh, Charles; Wong, Walter; Wong, Walter; Wang, Dave;
> > VPalawat at opuswave.com; kns10 at cs.columbia.edu
> > Cc: joon_maeng at vtel.com; hemantag at globespan.net;
> > schulzrinne at cs.columbia.edu; alan.johnston at 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
that
> > 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 at gts.com]
> > Sent: Monday, November 20, 2000 4:54 AM
> > To: Roy, Radhika R, ALCOO; Wong, Walter; Wong, Walter; Wang, Dave;
> > VPalawat at opuswave.com; kns10 at cs.columbia.edu
> > Cc: joon_maeng at vtel.com; hemantag at globespan.net;
> > schulzrinne at cs.columbia.edu; alan.johnston at 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
the
> > 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 at att.com]
> > Sent: Saturday, November 18, 2000 8:52 AM
> > To: Wong, Walter; Agboh, Charles; Wong, Walter; Wang, Dave;
> > VPalawat at opuswave.com; kns10 at cs.columbia.edu
> > Cc: joon_maeng at vtel.com; hemantag at globespan.net;
> > schulzrinne at cs.columbia.edu; alan.johnston at 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 at nuera.com]
> > Sent: Friday, November 17, 2000 2:48 PM
> > To: Roy, Radhika R, ALCOO; Agboh, Charles; Wong, Walter; Wang, Dave;
> > VPalawat at opuswave.com; kns10 at cs.columbia.edu
> > Cc: joon_maeng at vtel.com; hemantag at globespan.net;
> > schulzrinne at cs.columbia.edu; alan.johnston at 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
the
> > 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
power
> of
> > 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
> 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
that's
> > 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
the
> > 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 at att.com]
> > Sent: Thursday, November 16, 2000 11:29 PM
> > To: Agboh, Charles; 'Wong, Walter'; Wang, Dave; VPalawat at opuswave.com;
> > kns10 at cs.columbia.edu
> > Cc: joon_maeng at vtel.com; hemantag at globespan.net;
> > schulzrinne at cs.columbia.edu; alan.johnston at 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 at gts.com]
> > Sent: Thursday, November 16, 2000 6:06 AM
> > To: 'Wong, Walter'; Roy, Radhika R, ALCOO; Wang, Dave;
> > VPalawat at opuswave.com; kns10 at cs.columbia.edu
> > Cc: joon_maeng at vtel.com; hemantag at globespan.net;
> > schulzrinne at cs.columbia.edu; alan.johnston at wcom.com; David Daiker
> > Subject: RE: Draft Status Update
> >
> >
> > Hi Walter,
> >
> >
> > You are right, use of lightweight RRQ for additive registration is
tricky.
> > 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
the
> > 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 at nuera.com]
> > Sent: Wednesday, November 15, 2000 7:48 PM
> > To: Agboh, Charles; 'Roy, Radhika R, ALCOO'; Wang, Dave;
> > VPalawat at opuswave.com; kns10 at cs.columbia.edu
> > Cc: joon_maeng at vtel.com; hemantag at globespan.net;
> > schulzrinne at cs.columbia.edu; alan.johnston at 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 at gts.com]
> > Sent: Wednesday, November 15, 2000 7:48 AM
> > To: 'Roy, Radhika R, ALCOO'; Wang, Dave; VPalawat at opuswave.com;
> > kns10 at cs.columbia.edu
> > Cc: joon_maeng at vtel.com; hemantag at globespan.net;
> > schulzrinne at cs.columbia.edu; alan.johnston at wcom.com; Wong, Walter
> > Subject: RE: Draft Status Update
> >
> >
> > Hi,
> >
> > The problem with registering multiple alias addresses with a GK was
this:
> > 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
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 at att.com]
> > Sent: Wednesday, November 15, 2000 7:38 AM
> > To: Wang, Dave; VPalawat at opuswave.com; Agboh, Charles;
> > kns10 at cs.columbia.edu
> > Cc: joon_maeng at vtel.com; hemantag at globespan.net;
> > schulzrinne at cs.columbia.edu; alan.johnston at 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 at nuera.com]
> > Sent: Tuesday, November 14, 2000 3:33 AM
> > To: VPalawat at opuswave.com; Roy, Radhika R, ALCOO; Charles.Agboh at gts.com;
> > kns10 at cs.columbia.edu
> > Cc: joon_maeng at vtel.com; hemantag at globespan.net;
> > schulzrinne at cs.columbia.edu; alan.johnston at wcom.com; dwang at 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 at opuswave.com [mailto:VPalawat at opuswave.com]
> > > Sent: Monday, November 13, 2000 1:33 PM
> > > To: rrroy at att.com; VPalawat at opuswave.com; Charles.Agboh at gts.com;
> > > kns10 at cs.columbia.edu
> > > Cc: joon_maeng at vtel.com; hemantag at globespan.net;
> > > schulzrinne at cs.columbia.edu; alan.johnston at wcom.com; dwang at 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 at att.com]
> > > Sent: Sunday, November 12, 2000 10:53 AM
> > > To: VPalawat at opuswave.com; Charles.Agboh at gts.com;
> > > kns10 at cs.columbia.edu
> > > Cc: joon_maeng at vtel.com; hemantag at globespan.net;
> > > schulzrinne at cs.columbia.edu; alan.johnston at wcom.com; dwang at 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 at opuswave.com
> > > [mailto:VPalawat at opuswave.com]
> > > Sent: Friday, November 10, 2000 2:45 PM
> > > To: VPalawat at opuswave.com; Charles.Agboh at gts.com;
> > > kns10 at cs.columbia.edu
> > > Cc: joon_maeng at vtel.com; hemantag at globespan.net;
> > > schulzrinne at cs.columbia.edu; alan.johnston at wcom.com;
> > > dwang at 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 at vtel.com;
> > > hemantag at globespan.net; schulzrinne at cs.columbia.edu;
> > > alan.johnston at wcom.com;
> > > dwang at nuera.com; rrroy at 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 at gts.com]
> > > Sent:
> > > Wednesday, November
> > > 08, 2000 3:05 PM
> > > To: 'Kundan Singh'
> > > Cc:
> > > 'VPalawat at opuswave.com';
> > > ddaiker at cisco.com; joon_maeng at vtel.com;
> > > hemantag at globespan.net;
> > > schulzrinne at cs.columbia.edu; alan.johnston at wcom.com;
> > > dwang at nuera.com;
> > > rrroy at att.com
> > > Subject:
> > > RE: Message
> > > Mapping:
> > > SIP-H.323 interworking
> > >
> > > Hi,
> > >
> > > Can we keep Dave
> > > (ddaiker at cisco.com) in the
> > > discussion.
> > >
> > >
> > > regards
> > > charles
> > > -----Original
> > > Message-----
> > > From: Kundan Singh
> > > [mailto:kns10 at cs.columbia.edu]
> > > Sent:
> > > Wednesday, November
> > > 08, 2000 6:57 PM
> > > To: Agboh, Charles
> > > Cc:
> > > 'VPalawat at opuswave.com';
> > > ddaiker at cisco.com; joon_maeng at vtel.com;
> > > hemantag at globespan.net;
> > > schulzrinne at cs.columbia.edu;
> > > alan.johnston at wcom.com;
> > > dwang at nuera.com;
> > > rrroy at 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 at opuswave.com
> > > [mailto:VPalawat at opuswave.com]
> > > > Sent:
> > > Wednesday, November
> > > 08, 2000 5:45 PM
> > > > To: Agboh, Charles;
> > > ddaiker at cisco.com
> > > > Cc:
> > > joon_maeng at vtel.com;
> > > hemantag at globespan.net;
> > > >
> > > schulzrinne at cs.columbia.edu;
> > > alan.johnston at wcom.com; dwang at nuera.com;
> > > > rrroy at att.com;
> > > VPalawat at opuswave.com;
> > > kns10 at 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
> > > the draft comes
> > > to a complete
> > > and good shape, I will forward it
> > > > to all the editors.
> > > >
> > > > I will keep
> > > on updating
> > > 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 at gts.com]
> > > > Sent:
> > > Tuesday, November
> > > 07, 2000 11:19 AM
> > > > To:
> > > 'David Daiker'
> > > > Cc:
> > > Agboh, Charles;
> > > joon_maeng at vtel.com;
> > > >
> > > hemantag at globespan.net;
> > > schulzrinne at cs.columbia.edu;
> > > alan.johnston at wcom.com;
> > > > dwang at nuera.com;
> > > rrroy at att.com;
> > > VPalawat at opuswave.com;
> > > kns10 at 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 at 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,
> > > >
> > > >
> > > Sorry for
> > > the late response,
> > > I am just starting to look at
> > > > mapping
> > > 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 at mailbag.intel.com



More information about the sg16-avd mailing list