Session Initiation Protocol (SIP)-H.323 Interworking Requirements
RFC 4123

Reviewed by Spencer Dawkins, Gen-ART

His review:

Umm, I THINK the Designated Right Answer is that there's no IETF working group that's chartered to think about SIP-H.323 interworking, so there's no objection, right?

If I was worrying about anything more than this, I'd be worrying about

- an individual submission RFC with RFC 2119 MUST requirement language (how can this *not* be misleading?)

- limited functionality in call flows and omission of supplementary services (I'm not the only one who noticed, because this was pointed out in http://www.ietf.org/proceedings/00jul/SLIDES/sip-h323-reqs/sld011.htm at IETF 48)

- encouraging ("MAY") "a translation table to resolve the H.323 and SIP addresses to IP addresses" - isn't this the VoIP equivalent of hosts.txt?

I actually like this document, and I wish a WG was pushing back on these issues, because the result would be an improved document. I was on a two-hour call with a Tier One carrier this afternoon talking to them about their SIP-H.323 interworking requirements, so I think the topic matters. Are we just saying it doesn't matter in the IETF?

  Section 9 says:
  >
  > The IWF MUST NOT indicate that a user on one side has achieved a
  > certain level of trust without the ability to verify that.  For
  > example, if the SIP user was not authenticated, it would be
  > inappropriate to use mechanisms on the H.323 side, such as H.323
  > Annex D, that indicated that the user identity had been
  > authenticated.
  >
  I strongly encourage you to reword the first sentence without using
  the word "trust."  I propose:

    The IWF MUST NOT indicate the identity of a user on one side
    without first performing authentication.  For example, if the
    SIP user was not authenticated, it would be inappropriate to
    use mechanisms on the H.323 side, such as H.323 Annex D, to
    indicate that the user identity had been authenticated.

  Please spell out the first use of "RAS."