Re: [Sipping] SIP-H.323 design team

[Henning Schulzrinne <[e-mail]>]

Francois Audet wrote:
> Gonzallo and all,
> 
> 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 :-)

> 
> - 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).

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

> 
> - 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

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
> a free-form description of the various "gotchas" that may be encountered 
> when trying to
> interwork the two protocols.

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
> 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
> 

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