Subject: [AVT] One more change to draft-ietf-avt-rfc2833bisdata

From: Tom Taylor <[email-masked]>
Date: Thu, 03 Mar 2005 16:10:28 -0500

While digging requirements out of draft-ietf-avt-rfc2833bisdata-01.txt, I 
discovered a couple of typos in the section on V.18 terminals.  This led to 
reflect that after the general introduction to V.18 the section is really an 
extended example, and not one that's particularly needed.  I will propose on 
Monday that the detailed description of the V.18 probing be deleted, leaving only 
the general description.

Tom Taylor

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

---

From: Colin Perkins <[email-masked]>
Date: Sat, 5 Mar 2005 13:42:11 -0600

On 3 Mar 2005, at 15:10, Tom Taylor wrote:
> While digging requirements out of 
> draft-ietf-avt-rfc2833bisdata-01.txt, I discovered a couple of typos 
> in the section on V.18 terminals.  This led to reflect that after the 
> general introduction to V.18 the section is really an extended 
> example, and not one that's particularly needed.  I will propose on 
> Monday that the detailed description of the V.18 probing be deleted, 
> leaving only the general description.

Also in this draft, I notice (in section 2.6.1):

    It is assumed in all cases that the event reports described here are
    being transmitted in addition to other media content, typically G.711
    voice-band data.  A natural method to do this is to combine the
    voice-band data with event reports in an RFC 2198 [2] redundancy
    payload.

This should be clarified, since RFC 2198 only allows multiple 
representations of the same data to be conveyed, and this draft could 
be interpreted to allow multiplexing of text with some other audio data 
(which should be handled by a different RTP stream sent on the audio 
port, using a different SSRC).

The same issue appears in section 3.2.2: following RFC 2198 the example 
would playout ONLY the G.711 audio in the usual case, playing the data 
sent using the telephone events format only if a packet was lost (an 
offset of zero is not meaningful in RFC 2198). If the intent is to play 
the voice band data and the tones simultaneously, they should be sent 
as separate RTP streams - each with their own SSRC - to the same IP 
address and UDP port.

Colin

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sun, 6 Mar 2005 08:48:53 +0100

I can agree that if you want to shorten off the document, you could cut the V.18
description in 2.6.2 before the sentence:

" The rest of this section sketches the V.18 calling sequence."

You have correctly said that the implementor anyway must go back to the original
Recommendation to get full detail.

I would also suggest that you preserve a description of the XCI signal, that is intended
for stimulation of V.23 (Minitel ) textphones to respond

So, this part should be rescued from deletion and modified:
" 3.  Play out the XCI signal, a three second string of V.23 bit
       patterns defined in clause 3.13 of Recommendation V.18 and using
       the V.23 1200 bits/s upper channel.  The calling end gateway
       SHOULD send the V23Main event defined in Section 2.6.1 to
       indicate the nature of the content."
It seems that the V23Main does not contain details on the data bit contents that is
critical for the use of the XCI signal. XCI is designed so that a V.23 modem will perceive
it as a carrier, while a V.18 terminal should detect the XCI bit pattern and understand
that it is from another V.18, so that two V.18s in contact do not end up in V.23 mode.

So, for XCI, I suggest that you allocate an event code to the central part of it called
XCI marker in V.18. Call it XCIMark here and add it to the table in section 2.6.1.
including this description:

XCIMarker:  A signal in the V.23 upper channel by sending two bytes XCI marker containing
the data pattern (0) 1111 1111(1)(0)1111 1111(1) sent at 1200 bit/s.

XCI: A signal transmitted in high-band V.23 modulation to stimulate V.23 terminals to
respond and to allow detection of V.18 capabilities in a DCE.
The 3-s XCI signal uses the V.23 upper channel having periods of "mark" (i.e. 1300 Hz)
followed by the XCIMarker. The full definition is found in V.18 section 3.13.
The XCI signal SHOULD be sent by using the the V23Main and XCIMarker events to indicate
the nature of the content.

Gunnar
-------------------------------------------
Gunnar Hellström
Omnitor AB
Renathvägen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
[email-masked]
--------------------------------------------

>-----Original Message-----
>From: Tom Taylor [mailto:[email-masked]]
>Sent: Thursday, March 03, 2005 10:10 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: One more change to draft-ietf-avt-rfc2833bisdata
>
>

---

From: Tom Taylor <[email-masked]>
Date: Sun, 06 Mar 2005 16:29:22 -0500

Thanks, will do.