[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] Re: draft-jones-avt-audio-t38-04.txt



Hi Paul,

See below:

Paul E. Jones wrote:
Magnus,


It is not clear what you mean with adjusted. The RTP timestamp does need
to be specified by the RTP payload format. From RFC 3550, section 5.1:


<snip>

So if you could try to write out a definition for the RTP TS.


I believe this and other issues related to parameters and the offer/answer
model needs to go back into the T.38 spec.  The other fields, as you pointed
out, are defined there.  This draft is intended only to serve as the basis
for registering the MIME type for audio/t38.

I would even be favorable to removing the description of all of the
parameters and, again, just referencing the appropriate section(s) in T.38.
I feel like we're trying to solve two problems here, but the real work needs
to be done in T.38.


I agree that you will have to fix some things in T.38. For example the RTP TS definition definitly needs to go in there. Also the Offer/Answer text and mapping of MIME to SDP belongs there.


However the MIME types parameter list, needs to be part of the registration. The description of each parameter, probably should contain some informational parts and then normative references to the T.38 spec and the definition there.


[snip]


Now, what do we do about parameters, offer/answer, and the TS issue? Is it
a requirement that we include all of these optional parameters?

The reason as I see that you will need to include all parameters in the registration is that one should be able to look it up in the IANA register and see all parameters there. The MIME registration is the authorative document on what parameters that is available.


Rate would
need to be documented here, as I do not believe it is documented in T.38.
However, the T.38-specific attributes that would appear on the a= line are
documented in T.38.  It became clear to me as I was working on this that
T.38 needed more description of how these parameters should be used.  I
would prefer to not try to solve that problem in two places and just raise
this as an issue to the ITU to fix.


I also think that ITU needs to expand on the usage, for example with an offer/answer section and possibly also in the definition of the attribute themselves. As stated above, the parameter names and at least a reference to their definition needs to be included in the MIME registration draft.


Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com


_______________________________________________ Audio/Video Transport Working Group avt at ietf.org https://www1.ietf.org/mailman/listinfo/avt