Subject: RE: [Ieprep] Megaco

From: "King, Kimberly S." <[email-masked]>
Date: Thu, 16 Jan 2003 13:47:14 -0500

Thanks James, this is excellent.

>If the above scenario is expanded in such a way as there are two MGCs 
>controlling different GWs, this will require a Peer-to-Peer protocol 
>communication between MGCs - which is not MEGACO/H.248. Therefore, 
>MEGACO/H.248 doesn't need to be extended, but whatever Peer Signaling 
>protocol does - because none are capable today for this notification out
>of 
>MAYBE the recent effort by Jon Peterson with SIP-T. But I don't believe 
>SIP-T is generally planned between MGCs, is it? It's either SIP or BICC,
>I believe.

When I was talking with the "softswitch" type vendors, many indicated they
would use SIP-T between their MGCs.  SIP-T would encapsulate the HPC as part
of the ISUP so I suppose it depends upon whether the other MGC de-codes this
information.  Since SIP-T is really SIP tailored for telephony, I would hope
that any new mechanism that SIPPING produces for the Resource Priority
Header would be compatible with SIP-T.  That way, if the MGC's don't look at
encapsulated information, they would be a way to convey emergency
communications in this architecture.

Maybe Jon will help us out...pretty please. :-)

Kimberly

-----Original Message-----
From: James M. Polk
To: King, Kimberly  S.; Ieprep (E-mail)
Sent: 1/16/2003 1:06 PM
Subject: Re: [Ieprep] Megaco

At 11:17 AM 1/16/2003 -0500, King, Kimberly  S. wrote:
>Hi!
>
>Anybody want to investigate how Megaco can be used to support
>preferential treatment for certain calls (e.g., emergency
>services not limited to 911)?
>
>Part of what would be nice to understand is does a priority
>indicator need to be the Megaco protocol or could
>preferential treatment be done based upon something
>the MGC understands?

In a scenario in which a single MGC controls both GWs from the CSN, SS7 
should be able to provide the MGC enough information to not allow the
next 
available trunk to become free to anyone (internal MGC decision - not a 
protocol issue). If the call leg is hung up (meaning the dial user 
disconnects the line or hangs up the phone), the SUBTRACT command is
sent 
from the GW to the MGC, with the MGC then configuring this ETS-waiting 
trunk through the IP cloud (if and ) once an egress MG port becomes 
available in the appropriate path.

I don't believe MEGACO/H.248 needs adjusting in this scenario.

If the above scenario is expanded in such a way as there are two MGCs 
controlling different GWs, this will require a Peer-to-Peer protocol 
communication between MGCs - which is not MEGACO/H.248. Therefore, 
MEGACO/H.248 doesn't need to be extended, but whatever Peer Signaling 
protocol does - because none are capable today for this notification out
of 
MAYBE the recent effort by Jon Peterson with SIP-T. But I don't believe 
SIP-T is generally planned between MGCs, is it? It's either SIP or BICC,
I 
believe.

I don't believe there will be a need for protocol extension in the case 
where endpoints are not multiport MGs (RFC 3054), as this would fall
under 
the guidelines of the above (with the MGC controlling all incoming and 
outgoing control messages).

All GETS authentication and authorization will occur via the dial-pad
and 
therefore go through the MGC. There might be something within the
protocol 
that communicates out the MGC into the CSN for this authentication and 
authorization (SIGTRAN?) - but I don't believe that will be MEGACO/H.248

And preemption shouldn't change the protocol either, as the SUBTRACT 
command should accomplish this behavior quite well.

>Here is a specific example.  With the GETS service in the
>circuit-switched world, a PSTN switch will allow a GETS call
>a greater chance of success by giving it a larger timeout
>window to obtain a trunk. Now suppose we are in some kind of
>IP Bridging scenario and a MGC receive a SS7 message for
>setting up a GETS call.  (The part of SS7 that GETS uses for
>conveying priority is a codepoint in the CPC of the IAM.)
>Can a MGC do a similar thing of allowing some small interval
>for a gateway port to become available before returning a
>fast busy or something like that?

The MGC should control everything about an MG under its control except
for 
1 command (NOTIFY - which should be applicable in this case) and part of

another (SUBTRACT - which is used appropriately in this case).

>If so, this doesn't seem to require any
>Megaco protocol changes and
>I believe MGC's could have access to multiple
>gateways and hence even poll other gateways
>(in addition to trying the same gateway again later)
>based upon policy.  This would provide both
>queuing for resources and alternate routing.
>Plus, it isn't dependent upon the gateways which
>I think are fairly diverse in the number of
>vendors/gateways/etc. With this solution, the
>gateways themselves would have to understand
>no priority indicator or do anything about it.

I don't believe priority indication matters in a Client/Server control 
protocol such as this

>Alternatively, is this kind of timeout
>(if performed at all) done in the gateway
>whereby perhaps Megaco would need to pass
>some priority indicator?

Only two commands go from the GW to the MGC (NOTIFY and SUBTRACT). I 
believe these should solve what you're looking for.

>This solution might involve a Megaco protocol
>change (see below), would potentially be more
>difficult to implement because MG and MGC
>would have to understand the indicator and
>act upon it. Etc.
>
>Related questions:
>
>1. Can a MG have certain assets (e.g., ports) reserved
>exclusively for emergency services where the
>indicator triggers the MG's use of this asset?

IAM commands go to the MGC, not the MG. Trunk access is done through the

ADD, MOVE and MODIFY commands in MEGACO/H.248. A (RFC 3054) termination 
uses the NOTIFY command to an MGC to inform it that device is starting 
something (like dialing digits - that are mapped to a digit map for call

routing)

>2. Is there anything to forbid an MGC from tracking
>priority of on-going calls (e.g., MLPP scenario)
>and pre-empting calls using gateway resources?

Ahhh - MLPP and preemption changes things. There must be a something
like 
an MLPP Package created (through some ITU/IETF documents) indicating
what 
precedence values are allowed (I think this is only partially handled in

H.248v2). AUDITVALUE and AUDITCAPABILITIES commands will be needed by
the 
MGC to determine an MGs status and future capabilities. A NOTIFY
command, 
as part of the digit map, or as a separate command will be needed for
the 
user to convey which precedence level they wish engaged for that call 
(especially in the 3054 scenario)

>3. Is the Boolean emergency indication reserved for 911?

NENA doesn't want preemption, so this is a call routing issue within the

MGC to the outbound GW towards the appropriate PSAP.

>Could a MG be setup to place certain policy_data
>elements within an associated RSVP request for
>transport of IP media when it receives either a
>certain priority or emergency indicator?

Ask Tom Taylor (MEGACO Chair)

>Background:
>
>The framework http://www.ietf.org/rfc/rfc2805.txt states "
>   k.   Allow the MGC to specify that a given connection has higher
>       priority than other connections."
>
>6.1.1 Context attributes and descriptors of
>  http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-01.txt
>  "ò  The priority is used for a Context in order to provide
>  the MG with
>information about a certain precedence handling for a Context. The
>MGC can also use the priority to control autonomously the traffic
>precedence in the MG in a smooth way in certain situations (e.g.
>restart), when a lot of Contexts must be handled simultaneously.
>Priority 0 is the lowest priority and a priority of 15 is
>the highest priority.
>
>ò  An indicator for an emergency call is also provided to allow a
>preference handling in the MG."

This should be part of the digit map, and internal queuing, not a
protocol 
issue for 911 issues.

>Ideas?
>
>Kimberly
>_______________________________________________
>Ieprep mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ieprep

cheers,
James

               *************************************
"People generally demand more respect for their own rights than
                          they are willing to allow for others"
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep