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

From: "Vladimir Ulybin" <[email-masked]>
Date: Sun, 3 Jul 2005 17:44:53 +0300

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:[email-masked]] 
Sent: Saturday, July 02, 2005 6:18 PM
To: Vladimir Ulybin
Cc: [email-masked]
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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
>

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 04 Jul 2005 09:21:28 +0200

> primary IFP packet and do not increment SN if a fax packet is repeated.

There exist at least two possible ways of performing this without 
screwing up the RTCP statistics and fulfilling your other requirements:

The first one is to use FEC to provide the packet repetition. I would 
suggest that you use RFC 2733 to provide repetition in a smarter way. 
This way one FEC packet can cover a few RTP packets. If this is done 
using RFC 2198 packetization then you don't even need to run two RTP 
sessions.

The second is actually to use that Retransmission RTP payload format for 
repetitions. The payload format is really for repetitions and the spec 
provides with necessary information on bind and sync. Simple skip the 
NACK process.

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: [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Mon, 4 Jul 2005 09:49:05 +0100

> repetition is widely used by different gateway vendors.

As Magnus says, the RFC 2733 FEC format is appropriate, or the  
retransmission draft I suggested.

> primary IFP packet and do not increment SN if a fax packet is  

Not if you wish to be compatible with RTP: RTP requires the sequence  
numbers to be unique.

Colin