[Foip] SIP/SDP Problem and Recommendation Statement
gsalguei at cisco.com
Sat Mar 20 01:16:20 EDT 2010
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.
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
> "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
> "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
> FoIP mailing list
> FoIP at sipforum.org
More information about the FoIP