Re: [AVT] T.38 over RTP: RTP Sequence Number

On 4 Jul 2005, at 10:58, Vladimir Ulybin wrote:
> On my suggestion from 3 Jul 2005, at 15:44:
>>> I think we may use for RTP sequence number the same rules of
>>> incrementing as for T.38 UDPTL SN, i.e. increment SN per every new
>>> primary IFP packet and do not increment SN if a fax packet is
>>> repeated.
>
> Colin Perkins wrote:
>> Not if you wish to be compatible with RTP: RTP requires the sequence
>> numbers to be unique.
>
> 1. The current T.38 Rec. defining T.38 over RTP refers to RFC 3550  
> as a
> basic RTP protocol to be used for encapsulation.
> 2. The RFC 3550 does not define the packet repetition, also does  
> not use
> SHOULD or MUST for sequence number advances (in contrast to RFC  
> 2833bis
> were the MUST is used).

The RTP specification says "The sequence number increments by one for  
each RTP data packet sent".

> 3. Different RTP sequence numbers assigned to a fax state (or binary
> data) detected (or demodulated) at ONE moment of time cannot be
> considered as unique, because the one fax state will share some
> different packets. There is no mutual correspondence.

Using either RFC 2733, the RTP retransmission framework, or RTP over  
TCP will retain the sequence number. This is not a problem.

> 4. I try to find a more reliable transport for T.38 over RTP. The  
> blind
> assignment of new sequence numbers for ALL packets is full compatible
> with RFC 3550, but highly reduces the reliability of fax relay,  
> because
> gateways may not repeat fax packets.

As you say, gateways may not repeat the packets. This is because RTP  
requires all packets to have a unique sequence number - a gateway  
which suppresses the duplicates is behaving correctly.

> 5. As I understand from draft-ietf-avt-rtp-retransmission-11.txt the
> only problem of packet repetition with the same SN is a distorted RTCP
> statistics. In absence of other ways this violation is better than to
> loose connection during fax relay.

The AVT working group has developed three alternatives to improve the  
quality of the media: RFC 2733, the RTP retransmission framework, or  
RTP over TCP. I believe one of those would be appropriate for your  
usage.

Colin

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