Subject: RE: [AVT] hook-flash

From: John Sirney <[email-masked]>
Date: Fri, 29 Jun 2001 08:27:43 -0500

Hi:

I have been working with a Team at Cable Labs, that has been dealing with
using RFC 2833 and MGCP signaling to solve hookflash delays between Gr303
and MGCP NCS.

We have propsed a method using RFC 2833 to send ABCD Events between the MTA
and the IPDT to GR303 PSTN. This method solves hookflash delays, addresses
ring cadence timing, and allows on-hook transmission capabilities. It was
annouce june 20 at the Packet Cable Conference and should be release by mid
month.

In essence the MTA (IAD) would have to be able to send and receive the RTP
header information from the Gateway. The Gateway will send a AUEP for
capabilites at registration of the MTA. At CRCX the LCO parameters will call
out the connection parameters as well as the SDP. On of the big advantages
to this method is that it adds redunacy to the ABCD events instead of just
one NCS message.

Some discussion has been proposed to use RFC 2833 to notified between
endpoints of codec changes without notifing the Call Agent. This was not
part of the report. 

Cheers

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Tuesday, June 26, 2001 11:16 AM
To: Dan Wing
Cc: Romel Khan; [email-masked]
Subject: RE: [AVT] hook-flash

Dan Wing writes:
 > Hook-flash is a signaling message, so isn't sent over the bearer
stream.

Actually, the point of 2833 is to send signaling
messages.  I'd be surprised to hear that hook
flash wasn't supported.  It probably is though;
the named signaling events have a duration and you
should be able to deduce a flash by checking the
timestamps on onhook/offhook events.

		Mike

 > 
 > -d
 > 
 > > -----Original Message-----
 > > From: [email-masked] [mailto:[email-masked]]On Behalf Of Romel
 > > Khan
 > > Sent: Tuesday, June 26, 2001 7:44 AM
 > > To: [email-masked]'
 > > Subject: [AVT] hook-flash
 > > 
 > > 
 > > How is it possible to pass the hook-flash over RTP? 
 > > I did not seem to find mention of that in RFC2833 under line events.
 > > 
 > > Thanks.
 > > 
 > > Romel Khan
 > > Ph: (732)-363-0213, x241
 > > 
 > > 
 > > _______________________________________________
 > > Audio/Video Transport Working Group
 > > [email-masked]
 > > http://www.ietf.org/mailman/listinfo/avt
 > 
 > _______________________________________________
 > Audio/Video Transport Working Group
 > [email-masked]
 > http://www.ietf.org/mailman/listinfo/avt

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

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

---

From: "Chris Fulmer" <[email-masked]>
Date: Fri, 29 Jun 2001 10:52:16 -0400

> endpoints of codec changes without notifing the Call Agent. This was not

Why wouldn't this be signalled implicitly -- when you receive a packet with
a different payload type, it indicates that you're using a new codec.

This does imply some implementation details on either end -- in effect, each
end has to have a codec 'standing by' to accept the new payload.  I suspect
that only one codec would be needed, as the expected case would be along
the lines of "I'm doing G.723.1 and now I need to carry fax-over-G.711."
However, I'd argue that the 2833 approach has the same issue.  In either
case, you do end up with a problem in negotiation -- if, for example, one
end tells the other to switch to G.726 and the other end can't do G.726.

--
C