Subject: RE: [Sipping] SIP-H.323 design team

From: "Francois Audet" <[email-masked]>
Date: Thu, 20 Feb 2003 13:32:13 -0800

Gonzallo and all,

I have a few comments/concerns about this requirement document.

- Section 6 states that the IWF shall use the H.323 version 2
Recommendation. I don't believe
  this is a valid requirement. Many (if not most) implementations are up to
versions 3 and 4
  these days. We could either say nothing at all about H.323 versions, or
require version 2
  or above. In H.323, new versions need to be backward compatible with older
versions, so this
  shouldn't be an issue. 

- Many requirements are extremely vague. For example, things like 6.1.2 a
"the IWF shall support
  all the addressing shcemes of both H.323 and SIP". I'm not sure if this is
even feasible. 
  Requirement 8.1.1 is also very vague I also really doubt that it is even
possible to do so: 
  I'd recommend writing examples instead of a clear mapping).

- Certain requirements seem to modify the behavior that and H.323 endpoint
or GK may have. We
  can not impose system-wide behavioral changes on an existing H.323 (or
SIP) network. For example, 
  6.4 says that the pre-granted ARQ shall be supported by the IWF. It is
entirely up to the
  GK to decide which mode (pre-granted or not) will be used, not the IWF.
Perhaps I'm not reading
  the requirement properly and this requirement is just saying that the IWF
needs to support
  both pre-Granted ARQ and normal ARQ (if it is the case, then this bullet
should just be 
  merger with the previous requirement about vague requirements). One of the
reason I am
  thinking that the intent is to prescribe a specific behavior on the H.323
(and SIP) protocol
  is that the now-expired draft-agrawal-sip-h323-interworking-01.txt was
doing so. Are we
  thinking of ressucitating this draft, or are we thinking of starting from
scratch with
  a different approach?

- Section 6.5 uses the INFO method for sending DTMF information. I will
point out that H.323v4
  supports RFC2833 (the procedures for exchanging the necessary dynamic
payload type are 
  similar to the procedures used in SIP).

- Section 8.2 I like.

- Section 8.4 needs to be clarified (what is "invisible support"?).

- Section 12.4 is probably one of the most important to look into. It should
explain how the
  offer/answer model maps to H.323 (both fastStart and mid/call or slow
start). It should 
  talk about re-INVITE, UPDATE, OpenLogicalChannnel, a=sendonly/inactive,
TCS=0,etc. 
  I am pretty sure that there is no simple mapping as the models are quite
different.

- There should also be a section on in-band and out-of band media (early
media) and how they 
  map.

Lastly, we need to make sure that this document is meant to be informative
at best. I would
much prefer to have document explaining the various mismatches between SIP
and H.323 and how 
to minimize them than a document trying to describe a fixed mapping between
the two: more 
a free-form description of the various "gotchas" that may be encountered
when trying to 
interwork the two protocols.

For example, it could explain how opening logical channels in H.323 and the
terminal 
capability set negotiation process differ from the offer/answer model. I see
very little 
benefits in creating a document that would describe only a mapping for
"basic call setup" 
as this is not where people are going to have difficulties.

I am convinced that a "simple protocol mapping" approach such as the one
defined in the now
expired draft-agrawal-sip-h323-interworking-01.txt is not possible and that
instead the IWF 
will have to maintain full call control/state information in order to map
properly between 
the protocols. I think we would be doing developpers and service providers a
great disservice 
by issuing an RFC implying that a simple "protocol mapping" box might be
sufficient to allow 
for interworking between SIP and H.323. I'd rather see no interworking
document at all than 
a simplistic mapping document.

Comments?

François Audet

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Monday, February 10, 2003 12:17 AM
> To: sipping
> Cc: Dean Willis; Rohan Mahy; [email-masked]; Henning
> Schulzrinne; [email-masked]; [email-masked]
> Subject: [Sipping] SIP-H.323 design team
> 
> 
> Folks,
> 
> The requirements document for SIP-H.323 interworking is advancing:
> 
http://www.ietf.org/internet-drafts/draft-agrawal-sip-h323-interworking-reqs
-03.txt

Now, it is time to start thinking about the solution document. If there are
enough people willing to contribute, we intend to form a design team in
SIPPING.

The scope of the work will be most likely limited to basic call set-up.

Those of you who are interested in being part of such a design team, please
let me know.

Thanks,

Gonzalo
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Feb 2003 18:41:39 -0500

> I have a few comments/concerns about this requirement document.

Before we go there: the requirements document was last-called sometime 
in the last millenium and is now at the RFC editor. (The text will 
change a bit due to some last-minute editing to make it a bit more 
readable, but it's too late to make substantive changes).

draft-agrawal-sip-h323-interworking-reqs-03 was issued in early 2002, I 
think and was IESG approved for informational on April 18, 2002. Thus, 
your comments would have been somewhat more helpful about 18 months ago :-)

>   this is a valid requirement. Many (if not most) implementations are up 
> to versions 3 and 4
>   these days. We could either say nothing at all about H.323 versions, 
> or require version 2
>   or above. In H.323, new versions need to be backward compatible with 
> older versions, so this
>   shouldn't be an issue.
> 
> - Many requirements are extremely vague. For example, things like 6.1.2 
> a "the IWF shall support
>   all the addressing shcemes of both H.323 and SIP". I'm not sure if 
> this is even feasible.
>   Requirement 8.1.1 is also very vague I also really doubt that it is 
> even possible to do so:
> - Certain requirements seem to modify the behavior that and H.323 
> endpoint or GK may have. We
>   GK to decide which mode (pre-granted or not) will be used, not the 
> IWF. Perhaps I'm not reading
>   the requirement properly and this requirement is just saying that the 
> IWF needs to support
>   both pre-Granted ARQ and normal ARQ (if it is the case, then this 
> bullet should just be
>   merger with the previous requirement about vague requirements). One of 
> the reason I am
>   thinking that the intent is to prescribe a specific behavior on the 
> H.323 (and SIP) protocol
>   thinking of ressucitating this draft, or are we thinking of starting 
> from scratch with
>   a different approach?
> 

The final version has removed any mentioning of INFO. I caught this at 
the last minute :-)

> - Section 12.4 is probably one of the most important to look into. It 
> should explain how the
>   talk about re-INVITE, UPDATE, OpenLogicalChannnel, 
> a=sendonly/inactive, TCS=0,etc.
>   I am pretty sure that there is no simple mapping as the models are 
> quite different.
> 
> Lastly, we need to make sure that this document is meant to be 
> informative at best. I would

It will be, like all requirements documents.

> much prefer to have document explaining the various mismatches between 
> SIP and H.323 and how
> to minimize them than a document trying to describe a fixed mapping 
> between the two: more

Your contribution to such a document would be much appreciated. 
Unfortunately, it doesn't write itself...

> 
> For example, it could explain how opening logical channels in H.323 and 
> the terminal
> capability set negotiation process differ from the offer/answer model. I 
> see very little
> expired draft-agrawal-sip-h323-interworking-01.txt is not possible and 
> that instead the IWF
> will have to maintain full call control/state information in order to 
> map properly between
> the protocols. I think we would be doing developpers and service 
> providers a great disservice

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP