RE: [Sipping] draft-ietf-sipping-ToIP-00 - Section 8.4

"Gunnar Hellstrom" <gunnar.hellstrom@omnitor.se> Thu, 30 December 2004 20:09 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11986 for <sipping-web-archive@ietf.org>; Thu, 30 Dec 2004 15:09:57 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ck6np-0001qY-9O for sipping-web-archive@ietf.org; Thu, 30 Dec 2004 15:21:45 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck6ao-0007BB-6M; Thu, 30 Dec 2004 15:08:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck6Rg-0006In-Ko for sipping@megatron.ietf.org; Thu, 30 Dec 2004 14:58:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10865 for <sipping@ietf.org>; Thu, 30 Dec 2004 14:58:50 -0500 (EST)
Received: from av1-1-sn3.vrr.skanova.net ([81.228.9.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ck6cu-0001Xb-6r for sipping@ietf.org; Thu, 30 Dec 2004 15:10:38 -0500
Received: by av1-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 7910037F18; Thu, 30 Dec 2004 20:58:09 +0100 (CET)
Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 4BE0637F3C; Thu, 30 Dec 2004 20:58:09 +0100 (CET)
Received: from vit (h79n2fls31o265.telia.com [217.208.189.79]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id 235B638007; Thu, 30 Dec 2004 20:58:09 +0100 (CET)
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
To: Peter Ridler <ridler@softrac.ca>, 'IETF Sipping' <sipping@ietf.org>
Subject: RE: [Sipping] draft-ietf-sipping-ToIP-00 - Section 8.4
Date: Thu, 30 Dec 2004 20:57:56 +0100
Message-ID: <GHEPIJKACEKDGLKODIGJOEMPDMAA.gunnar.hellstrom@omnitor.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <BAYC1-PASMTP0459775758A8CB6756C17DED9B0@cez.ice>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56
Content-Transfer-Encoding: 7bit
Cc: 'Toip list' <toip@snowshore.com>
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 25eb6223a37c19d53ede858176b14339
Content-Transfer-Encoding: 7bit

The time synchronization requirements on text is low.
I suggest that you read a clock every time you copmpose a packet for transmission, and
convert it to a 1 ms base.

If you have a need to synch it to the audio channel, you can follow the general habits for
timing source synchronization of RTP streams.

For your IVR/ITR application, I realize that you could survive with longer transmission
intervals while collecting input from the user, but when the user is ready, she wants a
rapid response. If you really feel a need for increasing the transmission interval during
data collection, it needs to be combined with special action on the character marking the
end of the transaction. That starts to carry too far with application intelligence on the
transport level in my view, so I hope you are happy with the 300 ms default, and knowing
that during input pauses, nothing is transmitted. (except feeding out the redundancy ).

In rfc2793bis there is a section on expected bandwidth loads that you can read to get a
feeling of if the load is acceptable.

Gunnar


-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
Gunnar.Hellstrom@Omnitor.se
--------------------------------------------


>-----Original Message-----
>From: Peter Ridler [mailto:ridler@softrac.ca]
>Sent: Wednesday, December 29, 2004 8:36 PM
>To: 'Gunnar Hellstrom'; 'IETF Sipping'
>Cc: 'Toip list'
>Subject: RE: [Sipping] draft-ietf-sipping-ToIP-00 - Section 8.4
>
>
>Gunnar,
>
>Thanks for the reply.
>
>If indeed the 1000 is the clock rate, how is this value derived at?
>
>The negotiation of the transmission interval is where I was thinking that
>each end MAY suggest a timeout value that it is willing to accept (default
>would be the 300ms).  The application I have in mind is the case a TDD
>device is communicating via a PSTN gateway to a SIP IVR/ITR where it can
>handle a longer delay of text packets (say 500 - 1000ms range).  This would
>reduce the number of RTP packets going across the network.  BUT, I am quite
>happy with the fixed 300ms interval.
>
>Regards
>
>Peter
>
>
>
>
>> -----Original Message-----
>> From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se]
>> Sent: Wednesday, December 29, 2004 3:48 AM
>> To: IETF Sipping; Peter Ridler
>> Cc: Toip list
>> Subject: RE: [Sipping] draft-ietf-sipping-ToIP-00 - Section 8.4
>>
>> Peter,
>> I am glad you are looking at details of sipping-toip.
>>
>> The figure 1000 in the sdp line
>> >      a=rtpmap:98 t140/1000
>> is indeed a clock rate.
>>
>> You can read more about it in:
>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2793bis-09.txt
>> Where some requirements are stated for handling the timestamps.
>>
>> Even if it has little meaning for a text packet where text
>> characters are stored at the moment they are created rather
>> than by being sampled, we did not want to deviate from normal
>> RTP usage of that parameter.
>>
>> The clock is used for setting the timestamp of the text
>> packets, and for calculation of time offset for redundant
>> text, and can thus be used if there is a desire to time the
>> display of characters.
>>
>> ------
>>
>> Do you see a need for negotiation of the transmission interval?
>>
>> Regards
>>
>> Gunnar
>>
>> -------------------------------------------
>> Gunnar Hellstrom
>> Omnitor AB
>> Renathvagen 2
>> SE 121 37 Johanneshov
>> SWEDEN
>> +46 8 556 002 03
>> Mob: +46 708 204 288
>> www.omnitor.se
>> Gunnar.Hellstrom@Omnitor.se
>> --------------------------------------------
>>
>>
>> >-----Original Message-----
>> >From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]On
>> >Behalf Of Peter Ridler
>> >Sent: Tuesday, December 28, 2004 6:08 PM
>> >To: IETF Sipping
>> >Subject: [Sipping] draft-ietf-sipping-ToIP-00 - Section 8.4
>> >
>> >
>> >Hi,
>> >
>> >In section 8.4 of this draft states::
>> >
>> >--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--
>> >
>> >Text capability SHOULD be announced in SDP by a declaration in line
>> >with this example:
>> >
>> >      m=text 11000 RTP/AVP 98 100
>> >      a=rtpmap:98 t140/1000
>> >      a=rtpmap:100 red/1000
>> >      a=fmtp:100 98/98/98
>> >
>> >Characters SHOULD BE buffered for transmission and transmitted every
>> >300 ms.
>> >
>> >--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--
>> >
>> >On SDP line 2 (a=rtpmap:98 t140/1000) what does the 1000 stand for?
>> >
>> >Nominally it is the clock rate.  If just a filler, could it be the
>> >Timeout value i.e. 1000 = 1000ms or better yet (a=rtpmap:98
>> t140/300)
>> >300 = 300ms timeout value?
>> >
>> >Thanks
>> >Peter
>> >
>> >
>> >
>> >_______________________________________________
>> >Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> >This list is for NEW development of the application of SIP Use
>> >sip-implementors@cs.columbia.edu for questions on current sip Use
>> >sip@ietf.org for new developments of core SIP
>> >
>>
>>
>
>



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP