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@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 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@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 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@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 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@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 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@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 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 sameTransport 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 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@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:
- Registration and Address Resolution (Version 3)
- 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;
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 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@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,
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@mailbag.intel.com
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
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
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@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
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@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
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@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
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@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
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 (notreally
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 sameTransport 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
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@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:
- Registration and Address Resolution (Version 3)
- 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;
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 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@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,
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@mailbag.intel.com
participants (2)
-
Agboh, Charles -
Paul E. Jones