headers
shashanka bhat | 2 Apr 2009 10:20
Picon

Help needed

Hi All,

  1) Is b= line mandatory in ADD Ia request ?.
  2) Can we use TMAN package instead of b= line ?.

Cheers,
Giri Prasad.

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 1 comment |
headers
Schwarz Albrecht | 3 Apr 2009 08:17
Picon
Favicon

H.248 Ia Profiles: Admission Control vs Traffic Policing; RE: Help needed

Giri,

your questions are related to ETSI TISPAN.
Responses see inline.

Albrecht

________________________________

	From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org]
On Behalf Of shashanka bhat
	Sent: Donnerstag, 2. April 2009 10:21
	To: megaco <at> ietf.org
	Subject: [Megaco] Help needed
	
	
	Hi All, 
	
	  1) Is b= line mandatory in ADD Ia request ?.
[[Schwarz, Albrecht]]  see ETSI ES 283 018 for Ia V1 & V2, and 183 018
for Ia V3
Please note that the semantic of the "b=" line did change between V1 &
V2:

Tab. 87: NOTE 5:	It has to be noted that Ia profile version 1 has
a different semantic (see table 81 in ES 283 018 [22]) defined, which
incorporates also layer 2 bitrate.
A transformation between both "b=" line usages (in case of IP-over-L2)
is not straightforward because the transformation parameters are based
on L2-PCI and the IP packet rate. The L2-PCI is typically constant for a
dedicated L2 technology (like IP-over-IEEE 802.3 [i.9]), but the packet
rate is application-specific. E.g. the IP packet rate is usually unknown
at Ia for media-agnostic IP-to-IP interworking.

	
	  2) Can we use TMAN package instead of b= line ?.
[[Schwarz, Albrecht]]  No, not per se. You know that the two protocol
"tools" serve different purposes:
a) Admission Control (AC) => "b=" line provides input information for
the StAC (Stream Admission Control), which is related to transport
capacity reservation and allocation ... typically based on a CBR model
(i.e. peak-rate allocation) ... dependent of "b=AS:" semantic ...
b) Traffic Policing (TP) => tman is used for IP byte-rate policing
(which has nothing to do with AC)

=> that's the starting point of H.248 Ia Profile
=> any re-use of AC parameters for TP, or TP parameters for AC, may be
not excluded and is possible (with some limitations)
=> see Ia V2, clause 5.17.1.5 Bandwidth control - Reservation,
Allocation and Policing

	
	Cheers,
	Giri Prasad.
Permalink | Reply | 0 comments |
headers
Michael Dell | 29 Apr 2009 12:50
Favicon

Error descriptors within stream descriptors

Hi there
 
I have a question concerning the validity of adding an error descriptor in a command response within a stream descriptor - could the list please let me know if this should be valid Megaco (v3)?
 
When adding or modifying a multi-stream termination, we may identify an error with some subset of the streams.  In this case, where should the error descriptor(s) be located?  Specifically, is it valid to include an error descriptor within a stream descriptor?
 
For example, a termination with id "ip/1" has three streams (1, 2 and 3).  A request to modify all three streams can be accommodated on stream 2, but fails for stream 1 and stream 3.  The response I would like to send is as follows:
 
!/2 [16.16.16.16]:1
P=11{
C=200{
MF=ip/1{
M{
ST=1{
ER=449{"Unsupported or Unknown Parameter or Property Value"}},
ST=3{
ER=449{"Unsupported or Unknown Parameter or Property Value"}}
}}}}
 
The relevant part of the ABNF seems to suggest that an error descriptor is not a valid streamParm.  I believe this makes the above invalid Megaco.
 
However, the "H.248 Sub-series Implementers' Guide" says, in section 7.1.20:
 
An Error Descriptor shall be specified at the "deepest level" that is semantically appropriate for the error being described ...
...
If the error being described can be determined to be at a descriptor level, the Error Descriptor may be returned at the descriptor level.
 
Does this indicate that stream-scope error descriptors are, in fact, allowed?
 
Thanks in advance for your input
 
Mike Dell
Data Connection Ltd. 
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 0 comments |
headers
Sushil Kumar | 29 Apr 2009 10:44
Picon
Favicon

Query Regarding MG -MGC behavior

Hi All,

 

I had a query regarding MG - MGC behavior in H.248

 

Scenario is as follows:

 

1.       MG  is registered with only one  MGC (say MGC1) and MGC1 is in redundant mode (i.e. it has a  standby MGC2  )

2.       MG initiate Service change request “901” towards MGC1  and MGC1 in reply sends handoff to MG with MGCIdToTry = MGC2 .

3.       MG is now trying to register with MGC2  with message “903”.

4.       MGC2  ack the service change request from MG and after that there is no message exchange between MG and  MGC2 and in the mean time  ITO expired.

5.       Therefore MG now tries to register again with  MGC1 with service change request  “909 MGC Impending Failure”

6.       MGC doesn’t respond to this serviceChange request. MG performs  several retry for this above service change request in step 5.

7.       To this MGC1 sends  error =506 { "Number of TransactionPendings Exceeded" }

8.       Now what should MG do in response to this error ?

9.       Should MG  again retry to register itself with standby MGC2 considering its a failed registration attempt ?

Or

        In response of this error=506 ,  it should go to Out of service state considering it as failure in response of service change request?

 

 

Any help on this is really appreciated.

 

Thanks in advance.

 

 

Regards

Sushil

 

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 501 comments |
headers
Schwarz Albrecht | 30 Apr 2009 09:44
Picon
Favicon

Re: Query Regarding MG -MGC behavior

The right "MG strategy" is beyond the H.248 protocol itself, because dependent in engineering networks with regards to service/system availability.
It is almost impossible to define a single (qualitative) behaviour on a generic level.
You have to take into account the quantitative performance of your MGC entitities concering system availability (i.e., the estimated time or ratio of In-Service periods vs expected Out-of-Service periods).
 
On the highest level you could categorize MGCs (and MGs) in HA-MGC and LA-MGC implementations (high available vs low available).
 
Assuming that both MGCs got correct H.248 protocol implementations, it looks like that both MGC entities are rather LA-MGC types in your example.
That type of info would go into the configuration of timers, number of reattempts, etc ... and even the EMS/NMS behaviour.
 
-Albrecht
 
 
PS
H.248 does not know the term of a "standby" node, you should rather use the H.248 terms "primary", "first secondary", etc.
E.g., a primary MGC may itself implemented in a redundant manner (in order to achieve HA) by an internal architecture with a working & protection plane. See e.g. Fig. 1/H.Sup7.
 

From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of Sushil Kumar
Sent: Mittwoch, 29. April 2009 10:45
To: megaco <at> ietf.org
Subject: [Megaco] Query Regarding MG -MGC behavior

Hi All,

 

I had a query regarding MG - MGC behavior in H.248

 

Scenario is as follows:

 

1.       MG  is registered with only one  MGC (say MGC1) and MGC1 is in redundant mode (i.e. it has a  standby MGC2  )

2.       MG initiate Service change request “901” towards MGC1  and MGC1 in reply sends handoff to MG with MGCIdToTry = MGC2 .

3.       MG is now trying to register with MGC2  with message “903”.

4.       MGC2  ack the service change request from MG and after that there is no message exchange between MG and  MGC2 and in the mean time  ITO expired.

5.       Therefore MG now tries to register again with  MGC1 with service change request  “909 MGC Impending Failure”

6.       MGC doesn’t respond to this serviceChange request. MG performs  several retry for this above service change request in step 5.

7.       To this MGC1 sends  error =506 { "Number of TransactionPendings Exceeded" }

8.       Now what should MG do in response to this error ?

9.       Should MG  again retry to register itself with standby MGC2 considering its a failed registration attempt ?

Or

        In response of this error=506 ,  it should go to Out of service state considering it as failure in response of service change request?

 

 

Any help on this is really appreciated.

 

Thanks in advance.

 

 

Regards

Sushil

 

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 501 comments |
headers
Michael Dell | 30 Apr 2009 13:25
Favicon

Error descriptors within stream descriptors

Hi there
 
I have a question concerning the validity of adding an error descriptor in a command response within a stream descriptor - could the list please let me know if this should be valid Megaco (v3)?
 
When adding or modifying a multi-stream termination, we may identify an error with some subset of the streams.  In this case, where should the error descriptor(s) be located?  Specifically, is it valid to include an error descriptor within a stream descriptor?
 
For example, a termination with id "ip/1" has three streams (1, 2 and 3).  A request to modify all three streams can be accommodated on stream 2, but fails for stream 1 and stream 3.  The response I would like to send is as follows:
 
!/2 [16.16.16.16]:1
P=11{
C=200{
MF=ip/1{
M{
ST=1{
ER=449{"Unsupported or Unknown Parameter or Property Value"}},
ST=3{
ER=449{"Unsupported or Unknown Parameter or Property Value"}}
}}}}
 
The relevant part of the ABNF seems to suggest that an error descriptor is not a valid streamParm.  I believe this makes the above invalid Megaco.
 
However, the "H.248 Sub-series Implementers' Guide" says, in section 7.1.20:
 
An Error Descriptor shall be specified at the "deepest level" that is semantically appropriate for the error being described ...
...
If the error being described can be determined to be at a descriptor level, the Error Descriptor may be returned at the descriptor level.
 
Does this indicate that stream-scope error descriptors are, in fact, allowed?
 
Thanks in advance for your input
 
Mike Dell
Data Connection Ltd. 
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 1 comment |
headers
Sudhanshu Garg | 30 Apr 2009 14:18
Favicon

Re: Error descriptors within stream descriptors

Hi Mike,

 

Putting error descriptor inside another descriptor is not possible.

 

Regards,

Sudhanshu Garg

Engineering Project Manager

Ph: +91 124  4176218

Mob: +91 9999500798

A R I C E N T

From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of Michael Dell
Sent: Thursday, April 30, 20094:56 PM
To: megaco <at> ietf.org
Subject: [Megaco] Error descriptors within stream descriptors

 

Hi there

 

I have a question concerning the validity of adding an error descriptor in a command response within a stream descriptor - could the list please let me know if this should be valid Megaco (v3)?

 

When adding or modifying a multi-stream termination, we may identify an error with some subset of the streams.  In this case, where should the error descriptor(s) be located?  Specifically, is it valid to include an error descriptor within a stream descriptor?

 

For example, a termination with id "ip/1" has three streams (1, 2 and 3).  A request to modify all three streams can be accommodated on stream 2, but fails for stream 1 and stream 3.  The response I would like to send is as follows:

 

!/2 [16.16.16.16]:1
P=11{
C=200{
MF=ip/1{
M{
ST=1{
ER=449{"Unsupported or Unknown Parameter or Property Value"}},
ST=3{
ER=449{"Unsupported or Unknown Parameter or Property Value"}}
}}}}

 

The relevant part of the ABNF seems to suggest that an error descriptor is not a valid streamParm.  I believe this makes the above invalid Megaco.

 

However, the "H.248 Sub-series Implementers' Guide" says, in section 7.1.20:

 

An Error Descriptor shall be specified at the "deepest level" that is semantically appropriate for the error being described ...

...

If the error being described can be determined to be at a descriptor level, the Error Descriptor may be returned at the descriptor level.

 

Does this indicate that stream-scope error descriptors are, in fact, allowed?

 

Thanks in advance for your input

 

Mike Dell

Data Connection Ltd.


"DISCLAIMER: This message is proprietary to Aricent 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. Aricent 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
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 0 comments |

Gmane