Subject: RE: [Megaco] Call Hold with Megaco ?

From: "Bukka, Veerasham" <[email-masked]>
Date: Fri, 3 Aug 2001 09:15:17 -0400

Thanks, If possible can you give me some more info on SDP description:
In SIP, The party wishing to put the other party on HOLD sends a
(re)INVITE, with a session description containing a null (0.0.0.0)
address. When used with SDP, the ``c'' address field of one or more
media types is set to zero. What about megaco ?

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]]
Sent: Friday, August 03, 2001 8:04 AM
To: Bukka, Veerasham
Cc: [email-masked]
Subject: Re: [Megaco] Call Hold with Megaco ?

"Bukka, Veerasham" wrote:
> 
> Hi,
> 
> I am new subscriber to this mail list. Can anybody tell me how Call
Hold
> and call wait feature can be implemented with megaco? In fact I need
an
> example of SDP decription to do this. Or any pointers? Anything will
be
> highly appreciated.

One way would be to set the StreamMode in the LocalControlDescriptor
to "inactive".

Call waiting flash-hook could be handled by flipping the StreamModes
of two different terminations.

It would also be perfectly legal, although probably less efficient,
to subtract and add terminations.

-troy

_______________________________________________
Megaco mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/megaco

---

From: Troy Cauble <[email-masked]>
Date: Fri, 03 Aug 2001 10:53:05 -0400

It is not strictly defined in MEGACO.  It's up to whoever
is designing the call flow.  (I suspect that's true in SIP too.)

You could use the SDP techniques that you've seen in SIP 
in your MEGACO flow.

Alternatively, the technique I described, which resembles MGCP
flows I've seen, does not use the SDP for that.
It uses the StreamMode parameter in the LocalControlDescriptor.

-troy

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 03 Aug 2001 11:49:28 -0400

I agree with Troy.  MEGACO typically does not use SDP as extensively as
SIP.  This is partly because MEGACO supports both text and binary encodings
and SDP is used only with text encoding, so basing features on SDP, requires
a duplicate effort to accomplish the same for binary.  So MEGACO introduced
LocalControl that can contain properties that apply to both directions of
media flow and does not use SDP.  The streamMode can be used to turn on or
off each direction of flow without changing the SDP.

The latest SIP recommendation using SDP only turns off one direction of flow
(from SDP recipient to SDP sender) and the sender mutes themself (with no
message), but that assumes that the sender is an endpoint.  In MEGACO hold
must be initiated by an MGC (possibly after receiving some Notify from one
of the MGs), so both directions must be turned off by the message.  This can
be done by setting streamMode to "inactive".

Another method (although more complex) is to use a Topology descriptor.
Topology can control media flow between terminals in a context in more
complex ways than streamMode but certainly can be used to isolate a terminal
(block media flow).  But MEGACO makes support for the Topology descriptor
optional.

The SDP method could certainly be used for text-encoding cases, but since it
is not in the original RFC and there are other methods it may not be
implemented in many MEGACO MGs.  I assume that MGC would have to send "hold
SDP" in BOTH Local and Remote descriptors to turn off flow in both
directions.

MEGACO does not specify a single "official" way to do this, and both
streamMode and Topology should work on MGs that implement all of MEGACO, so
it is really up to an MGC to use whichever method it chooses.  But since
topology is optional, streamMode is probably the better choice.

--
Waiting for the other shoe to drop but hoping its a one legged man.
------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 06 Aug 2001 08:40:35 +0300

Hi,

For your information, call hold is now also discussed in the SIP world,
because there are a number of reasons why the current way may cause
problems. I proposed that "inactive" could be used there also, as an SDP
attribute parameter value.

Regards,

Christer Holmberg
Ericsson Finland