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