Hi ietf group,
The following are comments and recommended changes to the proposed
SIP-H.323 interworking definition as defined in the Internet draft,
draft-agrawal-sip-H.323-Interworking-01.txt. Other specifications
referenced as the basis for some of these recommendations include:
- ITU H.323, Packet-based multimedia communications systems, 09/99
- ITU H.225, Call signalling protocols and media stream packetization
for packet-based multimedia communication systems, 11/00
- ITU Q.850, usage of cause and location in the Digital Subscriber
Signalling System No.1 and the Signalling System No. 7 ISDN user Part,
05/98
- RFC 2543, SIP: Session Initiation Protocol, 03/99
- Draft-ietf-sip-rfc2543bis-03.txt, SIP: Session Initiation Protocol,
05/01
Recommended Changes:
------------------------------------
1. Typo on Page 7, Scenario 3 should be "IWF with SIP Server and without
H.323 GK" instead of "IWF with SIP Server and without SIP Server".
2. Typo on page 23, 9.2 explanation of CallerNotRegistered. ... it may
send a 400 (Caller not register) response to the SIP entity. It should
be " 401 (Unauthorized)" to synchronize with 8.2 message mapping.
3. The Draft ( in 8.2 section message mapping) does not cover all the
H323 reject Reasons as the following:
- For ReleaseCompleteReason,
newConnectionNeeded,nonStandardReason,replaceWithConferenceInvite,
genericdatareason, neededFeatureNotSupported,
tunnelledsignallingRejected are missing.
- For AdmissionRejectReason, exceedsCallCapacity, collectDestination,
collectPIN, genericDataReason are missing.
- For RegistrationRejectReason, UnregRequestReason, UnregRejectReason,
the draft does not address it at all.
4. The following changes are recommended when mapping the SIP status
code to H323 releaseCompleteReason.
- 406 Not Acceptable ---> map to noPermission instead of
undefinedReason. The comment on H225 specification (page 171) indicates
"Called Party's Gatekeeper rejects" for noPermission. On RFC 2543 (page
87), it also indicates " content characteristics not acceptable
according to the accept headers sent in the request" for 406 Not
acceptable
- 488 Not Acceptable Here ---> map to noPermission instead of
undefinedReason. The explanation for "488 Not Acceptable Here" is the
same meaning as 606, but only applies to the specific entity addressed
by the request-URL and the same request may succeed elsewhere.
- 600 Busy Everywhere ---> map to inConf instead of adaptiveBusy. The
explanation for "600 Busy Everywhere" is due to no other end point, such
as a voice mail system, will answer the request. It is the same meaning
as "no address in Alternative Address" defined for "inconf". Also, in
H.225, it maps inconf to 17 User Busy of Q.931/Q.850. (see page 26 of
Recommendation H.225 in section 7.2.2.8 Cause)
- 606 Not Acceptable ---> map to noPermission instead of
undefinedReason. The explanation for "606 Not Acceptable" is due to
requested media, bandwidth, or addressing style.
5. The following changes are recommended when mapping
ReleaseCompleteReason to SIP status code.
- noPermission ---> map to 606 Not Acceptable instead of 401
Unauthorized. In H.323, it is mapped to "111 Protocol error,
unspecified" for Q.931/Q.850, such that noPermission is better to map to
606 Not Acceptable than 401 Unauthorized.
- unreachableDestination ---> 488 Not Accept instead of 503 Service
Unavailable. In H.323, it is mapped to "38 Network out of order" for
Q.931/Q.850. Please see the above "488 Not Acceptable here" explanation
for SIP.
- UnreachableGatekeeper ---> 502 Bad Gateway instead of 503 Service
Unavailable. In H.323, it is mapped to "38 Network out of order" for
Q.931/Q.850
- badFormatAddress ---> 484 Address Incomplete instead of 400 Bad
Request. It is inline with the SIP to H.323 mapping.
- adaptiveBusy ---> 480 Temporarily not available in stead of 486 Busy
Here. In H.323, it is mapped to "41 Temporary Failure" for Q.931/Q.850.
AdaptiveBusy is a network busy. It is not a user busy as the definition
of "486 Busy Here". Also, in H.225, it maps adaptiveBusy to 41 Temporary
failure of Q.931/Q.850. (see page 26 of Recommendation H.225 in section
7.2.2.8 Cause)
- UndefinedReason ---> 400 Bad Request instead of 500 Server Internal
Error. In H.323, it is mapped to "31 Normal, unspecified" for
Q.931/Q.850
- facilityCalledDeflection ---> 380 Alternative Service in stead of 486
Busy Here. In H.323, it is mapped to "16 Normal call clearing" for
Q.931/Q.850 (note, SIP 380 Alternative Service is mapped to H.225
Facility in this draft). The comments on H.225 (page 171) indicates "
call was deflected using a Facility message". The "380 Alternative
Service" is a better choice than "486 Busy Here".
6. The following changes are recommended when mapping
AdmissionRejectReason to SIP status code.
- requestDenied ---> map to 403 Forbidden instead of 503 Service
Unavailable. 403 Forbidden indicates the request is rejected. For 503
Service Unavailable, the Client may allow to try it later.
- invalidEndpointIdentifier ---> map to 604 Does not Exist Anywhere
instead of 500 Server Internal Error. 604 Does not Exist Anywhere
indicates the To request field does not exist anywhere. For 500 Server
Internal Error indicates that the Server has unexpected condition
occurred.
7. The following changes are recommended when mapping
LocationRejectReason to SIP status code.
- requestDenied ---> map to 403 Forbidden instead of 503 Service
Unavailable. 403 Forbidden indicates the request is rejected. For 503
Service Unavailable, the Client may allow to try it later.
8. On page 25, 4th paragraph, "If, at any time, the IWF receives a Q.931
ReleaseComplete message, a H.323 call could not be established, the IWF
sends a 400 (bad Request) for the request failure with reason phrase
"H.323 call failed"" --- It should be based on the
releaseCompleteReason parameter containing in the ReleaseComplete
message to map a proper SIP status code for the SIP response message.
9. On page 25, 6th paragraph, ... the IWF sends a 501 (Not Implemented)
response to SIP entity. --- for un-resolved SIP address, it should send
a 404 Not found instead.
10. In section 10 (page 26), un-register interworking scenario between
H.323 and SIP should be addressed.
11. Typo, on page 27, section 10.1.2, 3rd and 4th paragraph, register
shall be registrar. - Occurs in three places.
12. On page 29, section 10.2, the call flow diagram is missing
converting "100 trying" SIP response message to Q.931 Call proceeding
message on the H.323 side. (See description on page 21, 2nd paragraph
for call proceeding.). For a normal H.323 call setup, the caller's SDP
on the SIP ACK message should be sent instead of sending the caller's
SDP on the SIP re-INVITE. If the ACK F9 is moved down until after OLC
Ack F20 is received, then there is no need for an INVITE F21, 200 OK
F22, and ACK F23 at all. By the way, I did not see any SIP phone handle
a complete transaction for a call without the caller's SDP. After ACK is
received, the Caller is connected to Callee's IP address but not the
other way around. (i.e. the Callee does not have an IP address to
connect). The retransmit the 200 OK addressed might occur and shall be
acceptable for this kind of interworking.
13. On page 32, e) Call from H.323 terminal to SIP terminal using
Overlapped sending.
First all, In SIP protocol, there is no such concept as an overlapping.
Based on the RFC 2543, a call leg is defined as the combination of
Call-ID, the local address of the participant (i.e. From (may include
Tag)), the remote address of the other participant (i.e. To). Any
change in one of the three fields is treated as a new call, such that
when a 484 Address Incomplete is responded from the SIP side and an ACK
is received, the transaction is over. There is no association between
the first INVITE (i.e. F3) and the next INVITE (i.e. F7) received. The
INVITE F7 is a brand new request message to the SIP. We should address
that the IWF shall suspend the H.323 side in case of overlapping, then
resume and launch the INVITE request message when all the digits are
received. In this case, the overlapping is on the H.323 side and is
transparent to the SIP side.
14. On page 33, it indicates " The detail of call flow messages are
given in Appendix C.4." But the Appendix C.4 does not address e) call
scenario at all.
15. On page 35, j) Call from SIP terminal to H.323 terminal using
overlapped sending.
For the same reason as described on page 32's comment, the call scenario
is not feasible. All the INVITE request messages, which contain
incomplete addresses, shall be ended by the ReleaseComplete message
indicating "badFormatAddress" in the ReleaseCompleteReason parameter.
16. On page 41, ii) with SIP Redirect call flow, 180 ring between SIP
redirect and IWF shall be removed. The 180 ring message shall be sent
from IWF to SIP EP directly.
17. Need to address how to utilize SIP Route and Record-Route headers to
ensure the SIP endpoint behavior in the IWF functionality.
18. On page 75, F21 INVITE is a re-INVITE request message such that the
Cseq shall be greater than 1024 as the initial INVITE (i.e. F2). It is
the same for all subsequent response (F22) and request (F23) messages.
In addition, the 200 OK shall not include SDP again. Otherwise, the IWF
shall re-pass the SDP to the H.323 side to modify the received callee's
SDP setting on the caller side even it is no change.
19. On Page 99, the C.4 does not apply to any call flow depicted on
section 10.2 at all.
20. On page 113, F6 INVITE request message shall have higher number Cseq
value. It is the same Cseq comment for the page 75.
21. On page D.3.5, requirement for overlapped sending should be
re-considered.
The above comments are contributed by Mark Chiou and Kevin Grove of
Santera Systems Inc.
Regards,
s
Mark Chiou Kevin Grove
System Architect Director, Partner
Development
Santera Systems Inc. Santera Systems Inc.
e-mail address: mark(_dot_)chiou(_at_)santera(_dot_)com
kevin(_dot_)grove(_at_)santera(_dot_)com
Work phone # : (972) 461-6474 (972) 461-6308