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

["Vladimir Ulybin" <Vladimir at audiocodes.com>]

Colin,

Possibly I used the term "retransmission" non-correctly for T.38 over
RTP. In the draft-ietf-avt-rtp-retransmission-11.txt, the term
"retransmission" is applied to packets retransmitted as a response onto
the request of packet receiver detected packet lost. Such retransmission
reduces a reliability of fax relay, because enlarges the round-trip
delay of fax commands and responses.

But I assume a simple packet repetition following an original packet
transmission to improve a reliability of delivering important T.30
commands or responses. This repetition shall be done without any request
on retransmission from remote side. In T.38 UDPTL protocol the packet
repetition is widely used by different gateway vendors.

For example, the original fax packet "t38-v21-preamble-flags" is sent
with sequence number SN at time offset To. Waiting for "v21-hdlc-data"
with SN'=SN+1 for redundant transmission "t38-v21-preamble-flags" is not
a good solution for reliable fax relay, because if the original
"t38-v21-preamble-flags" is lost in the network, then the redundant
"t38-v21-preamble-flags" may reach the packet receiver when a linked fax
disconnects on timeout or the V.21 re-modulation cannot be started.

The repetition of primary "t38-v21-preamble-flags" done one ore more
times k>=1 at offsets To + k*T (where T is a short interval T=0..Nms)
with the same SN solves the problem of packet lost in a best way. The
incrementing SN as it is recommended in RFC 3550 cannot be accepted for
this case because reduces reliability of V.21 relay in conditions of
packet lost.

The same is valid for some other T.38 packets like
"fcs-OK"/"sig-end/no-signal", etc. Furthermore, incrementing SN for
repeated "fcs-OK"/"sig-end/no-signal" containing T.30 data as secondary
packets may cause incorrect data modulation toward a fax machine.

Taking into account for T.38-over-RTP that

1. Fax relay is asynchronous communication having long periods of packet
absence;
2. The redundancy and repetition of important fax packets significantly
improves the fax session reliability;
3. Incrementing RTP sequence number for repeated T.38 packets cannot be
accepted;
4. Reliability of fax session has a much higher priority vs. a correct
RTCP statistics;

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.

Regards,
Vladimir Ulybin


-----Original Message-----
From: Colin Perkins [mailto:csp at csperkins.org] 
Sent: Saturday, July 02, 2005 6:18 PM
To: Vladimir Ulybin
Cc: avt at ietf.org
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir,

You might review draft-ietf-avt-rtp-retransmission-11.txt, which  
discusses this issue and proposes an RTP-friendly approach to  
retransmission.

Colin



On 30 Jun 2005, at 09:31, Vladimir Ulybin wrote:
> In T.38 UDPTL protocol, every primary fax packet has a unique  
> sequence number.
>
> To immune a fax session of packet loss in the network, gateways use  
> redundancy and packet retransmissions.
>
> When a T.38 UDPTL packet is retransmitted, the sequence number is  
> unchanged.
>
> In T.38 over RTP protocol, the RTP sequence number must be used.  
> The RFC 3550 defines the sequence number as monotonically  
> incremented by one for every packet sent to the network.
>
>
> If RTP sequence number is incremented per every retransmission,  
> then the retransmission of fax packets containing T.38 DATA packets  
> in primary or redundant RTP payloads is problematic because the T. 
> 30 data may be re-modulated incorrectly.
>
> The problem exists also for retransmission of T.38 INDICATOR  
> packets: If a primary T.38 INDICATOR is lost, the retransmitted T. 
> 38 INDICATOR arrived with a gap in RTP sequence number may be  
> delayed in packet recovery module, so the start of corresponding  
> fax signal may be delayed when it should not.
>
>
> The obvious solution is to increment RTP sequence number  
> conditionally by the same way as in T.38 UDPTL:
>
> The RTP sequence number is to be incremented per every new primary  
> fax packet, but remains unchanged if RTP packet transfers a  
> retransmitted primary fax packet.
>
>
> The questions:
>
> Does this conflict with some RTP protocol?
>
> What kind of interoperability problems (excluding RTCP statistics  
> of packet loss) may exist?
>
>
> Thanks,
>
> Vladimir Ulybin
>
> AudioCodes Ltd.
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>


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