Subject: [Megaco] Profiles

From: "SERDAR CABUK" <[email-masked]>
Date: Fri, 22 Mar 2002 10:49:33 +0200

Hi all,

Where can I find information about the Megaco profile structures, they are
not included in the RFC i guess?

Also which profile is used in the "Megaco/H.248 Call flow examples" draft,
which has physical termination names such as Trunk1/line1?

Thanks,

Serdar Cabuk

                    [email-masked]                                                                                               
                    .com                 To:     [email-masked]                                                       
                    Sent by:             cc:     [email-masked]                                                                 
                    megaco-admin@i       Subject:     Re: [Megaco] Embedded descriptor processing with buffered events           
                    etf.org                                                                                                      

                    03/22/2002                                                                                                   
                    07:24 AM                                                                                                     

Hi Giri

Oops! there was a typo error.
It is "activate embedded descriptor" and not "activate embedded events
descriptor".
I think that makes things more clear.

But, now let me re-orient my question a bit...
RFC 3015..7.1.9
"(Note -  for purposes of EventBuffer handling, activation of an embedded
EventsDescriptor is equivalent to receipt of a new EventsDescriptor)."
RFC does not say anything about the treatment for embedded signal
descriptor for purposes of EventBuffer handling.

Assuming a scenario when eventbuffercontrol property is lockstep and
events are being buffered by the MG. If a new event descriptor is received
with an embedded event and signal descriptor -

E=10{ p1/e1{ EB{ SG=p1/s1,E=20{ p1/e2{ EB{SG=p1/s2}}}}}}
Note: Package 'p1' is defined with events 'e1','e2' and signals 's1','s2'.

Assuming events in the eventbuffer FIFO are - e1-e2-e1-e2.
a-   Remove event e1 from event buffer.
b-        NOTIFY event e1.
c-        Activate embedded descriptor.
d-        Start signal s1 ??
e-        Remove event e2 from event buffer.
f-        NOTIFY event e2.
g-        Stop signal s1 ??
h-        Start signal s2.

The questions are:
Signals can be stopped by a new signals descriptor or when an event is
detected on a termination. The detection of event in case of eventsbuffer
handling should be construed as the instant of event buffering OR event
Notify ? There is no clarification on this in RFC/ IG.

In the example above NOTIFY is considered as the instant when signals are
stopped. If this is OK, we have a situation when MG is starting and
stopping
the signal s1 in a single command processing (ADD/ MODIFY)....virtually
at the same instant. Is this OK although it seems to be an unnecessary
overhead on MG?

Any comments/ clarifications?

Thanks
KapilNayar
Hughes Software Systems Ltd.
http://www.hssworld.com

Giri Rajasekhar Saladi <[email-masked]> on 03/21/2002 08:36:54
PM

Please respond to [email-masked]

To:   Kapil Nayar/HSS@HSS
cc:   [email-masked]

Subject:  Re: [Megaco] Embedded descriptor processing with buffered events

Hi Kapil,
     I guess, that's the interpretation from MGC's point of
view, with a minor modification to the sequence i.e. swap 3 and 4
('Activate embedded event descriptor' and 'Start signal s1 ??'.
It would be better, if we start activating the EmbeddedEventsDescriptor
the last in the event handling process, as activating an
EmbeddedEventsDescriptor starts the next cycle of event handling.
This assures us the correct sequence of operations.
Any comments?
Regds.,
Giri

[email-masked] wrote:
>
> Hi
>
> Assuming a scenario when eventbuffercontrol property is lockstep and
> events are being buffered by the MG.
>
> If an event descriptor is received with an embedded event and
> signal descriptor -
> E=10{ p1/e1{ EB{ SG=p1/s1,E=20{ p1/e2{ EB{SG=p1/s2}}}}}}
>
> Note: Package 'p1' is defined with events 'e1','e2' and signals
's1','s2'.
>
> Assuming events in the events buffer are - e1->e2->e1->e2.
> The normal processing upon receiving the above events descriptor shall
> be:
> -    Remove event e1 from event buffer.
> -    NOTIFY event e1.
> -    Activate embedded event descriptor.
> -    Start signal s1 ??
> -    Remove event e2 from event buffer.
> -    NOTIFY event e2.
> -    Stop signal s1 ??
> -    Start signal s2.
>
> The MG is starting and stopping the signal s1 at the same instant.
> Is this the correct interpretation and expectation from MGCs point
> of view.
> RFC does say that in the above situation treat an embedded descriptor
> as a new events descriptor. However, it does not say anything about
> the embedded signals descriptor in above situation.
> Any comments...
>
> Kapil Nayar
> Hughes Software Systems Ltd.
> http://www.hssworld.com
>
> "DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited
> (HSS) and is intended solely for the use of the individual  to whom it is
> addressed. It may contain  privileged or confidential information  and
should
> not be circulated or used for any purpose other than for what it is
intended.
If
> you have received this message in error, please notify the originator
> immediately. If you are not the intended recipient, you are notified that
you
> are strictly prohibited from using, copying, altering, or disclosing the
> contents of this message. HSS accepts no responsibility for loss or
damage
> arising from the use of the information transmitted by this email
including
> damage from virus."
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco

--

Giri Rajasekhar Saladi
HCL Technologies Ltd.,
51, Jawaharlal Nehru Road
Guindy Industrial Estate,
Ekkatuthangal,
Chennai - 600 097.

Phone Off : +91 44 233 4174 or +91 44 233 4181 Extn. 233
Fax : +91 44 234 4256
e-mail : [email-masked] <mailto:[email-masked]>

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

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