[Foip] SIP/SDP Problem and Recommendation Statement

[Steve Underwood]

On 03/17/2010 10:59 PM, Kevin P. Fleming wrote:
> First, let me apologize for the time it has taken to get this draft sent
> to the group; I've been swamped with working on our actual FAX/T.38
> products (surprisingly enough) and that work has resulted in gaining a
> better understanding of these issues... so as a small value, I've been
> able to better interpret the T38-2009 draft and come up with
> recommendations that seem to fit with our goals.
>
> I'd like to keep discussion of the content of this document on the
> mailing list, rather than sending around modified copies with changes,
> questions, etc. contained within them. The 'edited document' format is
> not very amenable to discussion and reaching consensus amongst a group
> of participants, and it doesn't make for a searchable archive either. As
> each thread on the list reaches consensus, I'll incorporate the desired
> changes into the document and send out a new draft.
>
> Finally, I'd like to also begin work on formatting this an actual ITU-T
> contribution document so I can learn what is required; is there a
> standard template to be used for making contributions?
>
> Also, for those of you who are familiar with the ITU-T processes, at
> what point does 'editorial' work begin on the study group drafts? The
> T38-2009 draft is littered with grammatical and typographical errors,
> outdated RFC references, etc.
>
>    
"Definitions and References, point 11 "

I'm not clear where the term IAF was first defined (if it ever has been 
unambiguously defined), but I don't think it was in T.38-2007 Amendment 
3. As far as I know, there have been no amendments issued for that 
document.

"Trigger of T.38 switchover "

This section describes the problem of detecting tones through a 
compressed speech codec. It doesn't mention that some systems send 
RFC4734 messages to report CNG, CED, V.8 and FAX preamble events to 
avoid this. There are questions about what action it is appropriate to 
take if these messages are seen.

"T.38 requested on initial INVITE "

The recommendations don't provide a recommendation for how initial T.38 
INVITEs from pre-T.38-2009 entities are best handled.

"Minimum/maximum redundancy IFPs in UDPTL frames "

Why are the minimum and maximum values only documented for 
t38UDPRedundancy? The same issues apply to t38UDPFEC.

If t38UDPFEC is used, some T.38 entities will send a few UDPTL packets 
with redundancy, until enough history has been accumulate for the full 
use of t38UDPFEC. I think some words about this mixed mode behaviour are 
worthwhile. Personally, I would say it shouldn't be allowed, but others 
may disagree.

There is no recommendation about more sensible handling of the max IFP 
size when redundancy is used.

"T.38 Session Parameter: T38FaxVersion "

The T38ModemType parameter is really sad. They seem to have addressed 
the lack of a clear statement of capabilities with another lack of 
clarity. Why didn't they explicitly list the modem capabilities, rather 
than have a whole new vague "It can do V.34" or "It can't do V.34" 
indicator. This may not be a big issue in practice, but is still seems 
the kind of narrow thinking that lead to the mess we are trying to sort 
out.

"T.38 Session Parameter: T38FaxFillBitRemoval "

I see no reason why this parameter should depend on the use of 
redundancy. Its true that communication is fragile for non-ECM data 
without redundancy, but the use of fill bit removal doesn't make it any 
more fragile. In fact, it may marginally improve things by reducing the 
amount of data sent that could potentially be lost.

"T.38 Session Parameter: T38FaxTranscodingMMR "
"T.38 Session Parameter: T38FaxTranscodingJBIG "

These are described differently, but it seems the issues associated with 
them are identical.

"T.38 Session Parameter: T38FaxMaxDatagram "

This section still looks very close to my original wording. However, I 
thought people had pointed out a couple of things I missed in the T.38 
spec, which tied down a couple of issues I described as open ended.

In the recommendations I think it is worth pointing out why a 
redefinition of an existing parameter is tolerable - that it is so 
totally unreliable in the field today, that we don't risk breaking 
anything.

Regards,
Steve