[Foip] SIP/SDP Problem and Recommendation Statement

[Gonzalo Salgueiro]

Thanks Steve for your comments.

I would encourage for everyone to please take some time and provide any final comments to Kevin regarding this documents so we can finalize it.

Gonzalo
<as chair>


On Mar 18, 2010, at 9:40 AM, Steve Underwood wrote:

> 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
> 
> _______________________________________________
> FoIP mailing list
> FoIP at sipforum.org
> http://sipforum.org/mailman/listinfo/foip