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

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Hi Paul,

Some replies and further concerns over the T.38 RTP payload format.

I have now scanned the T.38 Amendment 2 and the original specification. 
And I have some concern over the RTP payload format itself. I found the 
following text in the T.38 amendment 2:

Each RTP packet starts with a fixed RTP header. The following describes 
the payload specific fields of the RTP fixed header when the RTP packet 
encapsulates fax:

Payload Type (PT): The payload type for fax is a dynamic payload type 
identified by the name “t38”. If redundancy is used per RFC-2198, the 
payload type must indicate the payload format RED (as per RFC-2198).

Marker (M) bit: The marker bit is not used for fax and MUST be set to 
zero. The Marker bit should be
ignored by the receiver of the packet.

I can't find anywhere that you define the RTP TS field. The timestamp 
must also be defined by a RTP payload format. If you do not use it for 
any purpose, then you should at least define it as being the timestamp 
at the time of the sending so that the RTCP jitter measurements work.

See further comments below.

Paul E. Jones wrote:

[snip]
> It is strange as defined. What I would prefer is that devices would just
> use
> the same value they use for audio codecs, which is typically 8000.
> Since
> the usage of this MIME type will be with TDM circuits, it is probably
> reasonable to just set it to 8000, though I'd prefer it to match the
> voice
> codec-- perhaps the voice codec rate is 16000.  I'm open to suggestions.

I don't see a problem with defining 8 kHz as default, and then recommend 
that in any gateway cases the RTP TS rate is equal to the audio RTP TS 
rates used in the same session.

However I think ITU must start with defining what the TS field actually 
contains.

[snip, answered in another mail]

> > Section 6. Offer/Answer: I think I understand how you intended this to
> > work. I think it can benefit from further review and discussion.
> >
> > The draft contains three different policies for different parameters:
> >
> > A. Declarative parameters where the answers is not allowed to change
>
> it
>
> > in the answer.
> >
> > B. parameters that are negotiated.
> >
> > C. Declarative parameters that are allowed to be set independently.
> >
> > Case A is a payload format configuration parameter. Although I don't
> > fully why it needs to be set symmetric. Please clarify why rate must
>
> be
>
> > the same in both direction. Or is this simple to ensure that one can
> > actually determine what PTs actually was in the offer and which are
> > actually answered?
>
>
> Rate really doesn't matter.  Quite simply, I just wanted to say
> something
> concrete.  We could say that a device can set it to whatever it wants.
> It
> will not impact T.38.

I think it is reasonable to maintain the rate as fixed between offer and 
answer as the first identifier of the configuration. Otherwise it will 
be impossible to map if the offer and answer uses different PT numbers 
for the same configuration.


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