Re: [Megaco] Regarding audio record

Christian Groves <Christian.Groves@nteczone.com> Sat, 26 September 2009 04:23 UTC

Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: megaco@core3.amsl.com
Delivered-To: megaco@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8686D3A68AE for <megaco@core3.amsl.com>; Fri, 25 Sep 2009 21:23:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.805
X-Spam-Level:
X-Spam-Status: No, score=-2.805 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQvDtyLgWZ4g for <megaco@core3.amsl.com>; Fri, 25 Sep 2009 21:23:50 -0700 (PDT)
Received: from ipmail02.adl6.internode.on.net (ipmail02.adl6.internode.on.net [203.16.214.140]) by core3.amsl.com (Postfix) with ESMTP id F29773A67ED for <megaco@ietf.org>; Fri, 25 Sep 2009 21:23:49 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtQAAAM0vUp20OgX/2dsb2JhbAAI1zeCMIFuBQ
X-IronPort-AV: E=Sophos;i="4.44,455,1249223400"; d="scan'208";a="38849834"
Received: from ppp118-208-232-23.lns10.mel6.internode.on.net (HELO [127.0.0.1]) ([118.208.232.23]) by ipmail02.adl6.internode.on.net with ESMTP; 26 Sep 2009 13:55:01 +0930
Message-ID: <4ABD9794.3060108@nteczone.com>
Date: Sat, 26 Sep 2009 14:24:52 +1000
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: shalu dhamija <shalu.dhamija@rancoretech.com>
References: <20863476.889411253858393581.JavaMail.root@mail01>
In-Reply-To: <20863476.889411253858393581.JavaMail.root@mail01>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: megaco <megaco@ietf.org>
Subject: Re: [Megaco] Regarding audio record
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Gateway Control <megaco.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/megaco>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Sep 2009 04:23:54 -0000

Hello Shalu,

The StreamID is the means to identify a particular media stream on a 
Termination where multiple streams are used. If multiple terminations 
exist in a context with the same streamID then these are interconnected. 
However there may also be a single termination in a Context with 
multiple streams (i.e. for announcements, recordings etc) in this case 
interconnectedness is not applicable.

The streamID may or may not be used with signals. Its up to the MGC to 
decide. If the termination only has one stream then there's little point 
in sending the streamID because its clear to the MG what stream you're 
talking about.
Where multiple streams are on a termination then it makes more sense to 
send the streamID as it may not be clear to the MG which stream it has 
to apply the signal on. e.g. there's two audio streams and the MGC asks 
to send an announcement? which stream should it send the announcement 
on? or both?

With regards to the StreamID being audio or video, these are not a 
property of the StreamID but the contents of the local and remote 
descriptor that determine this.

The format of the file to be recorded is given by the file extension in 
the URL.

Christian


shalu dhamija wrote:
>
> Thanks Christian and Tom for the clarifications. Now I am clear about 
> the input streams and mixed streams used for the audio/multimedia 
> recording.
>
>  
>
> I have a doubt on the StreamID parameter. StreamID is just a means to 
> indicate which media flows are interconnected. If I don’t mention any 
> StreamID in the signals descriptor then the default is zero. This is 
> in accordance with H.248.9
>
>  
>
> "Signals that occur in a Signals Descriptor have an optional StreamID 
> parameter (default is 0, to indicate that the signal is not related to 
> a particular media stream)."
>
>  
>
> So, that means every time I have to mention the StreamID in the 
> signals descriptor. How MG distinguishes that the particular StreamID 
> mentioned by MGC is related to audio or video?
>
>  
>
> And another doubt is: How do MGC tells MG about the format of the file 
> to be recorded ?
>
>  
>
> Thanks and Regards,
>
> Shalu Dhamija
>
>
> ----- Original Message -----
> From: "Christian Groves" <Christian.Groves@nteczone.com>
> To: "Tom Taylor" <tom.taylor@rogers.com>
> Cc: "shalu dhamija" <shalu.dhamija@rancoretech.com>, "megaco" 
> <megaco@ietf.org>
> Sent: Friday, September 25, 2009 5:07:13 AM GMT +05:30 Chennai, 
> Kolkata, Mumbai, New Delhi
> Subject: Re: [Megaco] Regarding audio record
>
> Hello,
>
> Actually there's more to it.... The H.248.9 text mentions input stream
> because a H.248/Megaco stream is bi-directional. Typically the signal is
> applied at a termination level because the most common case is that
> there would be only one audio stream. So the MG knows which stream to
> apply the recording to. In the case a termination has multiple audio
> streams you can use the "StreamID" parameter associated with the Signal
> (this is core H.248) to indicate which stream is to be recorded.
>
> In order to capture the incoming stream from all users the signal
> "direction" parameter is used. Normally the "external" direction is
> recorded however if "internal" is specific then the MG will record the
> audio received by the termination from all other terminations in the
> Context. i.e. the mixed stream.
>
> Regards, Christian
>
> Tom Taylor wrote:
> > Hi.
> >
> > I was the editor of that package years ago.
> >
> > A Signals Descriptor applies to a specific termination. That means you
> > can select which party is to be recorded. If you look at the
> > definition of the PlayRecord signal, it says it records the incoming
> > stream from the user. So that is all there is to it.
> >
> > Tom Taylor
> >
> > shalu dhamija wrote:
> >>
> >> Hi All,
> >>
> > ...
> >
> >> I have a query on advanced audio server recording (aasrec) package.
> >> According to 3GPP 23.333, the functional requirements for the audio
> >> record
> >> states that:
> >>
> > ...
> >>
> >> “The MRFC shall request the MRFP to start the audio record from one
> >> or all
> >> parties connected in a call/session. If it is to record one party in a
> >> call/session, only the input stream of the party is recorded. If it
> >> is to
> >> record all parties in a Call/session, the mixed stream of all 
> parties is
> >> recorded. “
> > ...
> >>
> >> I am unable to understand that how to specify the input stream of the
> >> party
> >> in a Megaco message.   Can anybody illustrate how MRFC tells MRFP
> >> about the
> >> input stream to be recorded? I have not got any parameter in the aasrec
> >> package. In this package, the mandatory parameter in the signals
> >> descriptor
> >> is the recording identifier (rid) which I think is just the URI
> >> (where the
> >> recording is to be stored).
> >>
> > ...>
> >> Thanks and Regards,
> >>
> >>
> >>
> >> Shalu
> >>
> > ...
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www.ietf.org/mailman/listinfo/megaco