Subject: [AVT] Trunk unavailable event in 2833bis

From: Tom Taylor <[email-masked]>
Date: Tue, 02 Dec 2003 16:02:52 -0500

What was the reasoning for not defining "trunk unavailable" as a state 
in 2833bis?  It would seem natural to do so, and to say that if the 
duration expires without a refresh, the receiver assumes that the state 
has expired.  (That is, you don't have to define and keep sending "trunk 
available" events.)

Tom Taylor

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

---

From: "Rajesh Kumar" <[email-masked]>
Date: Tue, 2 Dec 2003 16:43:08 -0800

This was at the recommendation of the AVT folks that on/off state
signaling was out of the scope of RFC 2833.The trunk available acts like
a per-DS0 AIS. In North America, you do not need it because you can use
the signaling path to take individual DS0s out of service. In the ETSI
countries, this is done by sending special patterns in the bearer path.
Now you could use RTP to send those patterns but that would be less
efficient since you would need to send the bit pattern continuously
without using VAD. We concluded that an RFC 2833 event message with
periodic, albeit longer, refresh was more efficient.

Rajesh Kumar

> -----Original Message-----
> From: Tom Taylor [mailto:[email-masked]]
> Sent: Tuesday, December 02, 2003 1:03 PM
> To: Rajesh Kumar; [email-masked]
> Subject: Trunk unavailable event in 2833bis
>

---

From: "Rajesh Kumar" <[email-masked]>
Date: Tue, 2 Dec 2003 16:48:18 -0800

Another point: I need to correct an unintentional typo in both your
email and mine. The event is "trunk UN-available" lest I cause
unnecessary heartburn about the need to periodically refresh a trunk
available event!

> From: Rajesh Kumar
> Sent: Tuesday, December 02, 2003 4:43 PM
> To: Tom Taylor; [email-masked]
> Subject: [AVT] RE: Trunk unavailable event in 2833bis
>