Draft Status Update
Agboh, Charles
Charles.Agboh at GTS.COM
Mon Nov 27 14:09:22 EST 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 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