Sachin | 16 Jul 09:32 2008
Picon

Error 402 Unauthorized

Hi,
 
MG has no knowledge of association with the MGC. MGC sends any command to that gateway. The expected reply to this is an error 402. 
 
The MG in the current scenario should not accept any transaction from the MGC. So at what level the error 402 to be sent, is it at transaction level or at the command level.
 
Please help.
 
Thanks
Sachin
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Raphael Tryster | 16 Jul 16:39 2008

Re: Error 402 Unauthorized

You answered it yourself, didn't you?  The error is at the transaction level, so the reply should be at the transaction level too.
 
However, you may wish to consider an alternative.  In 2002, I asked the following question:
 

I have seen a number of discussions in the archive about the following statement:
"Responses must be sent to the address and port from which the corresponding commands were sent".
The discussions relate mostly to failover and handover situations, but I could not find any discussion of what happens when a rogue MGC sends a command to an MG with which it has not established a control association.   One rule that may be relevant here is:

"It is possible that the reply to a ServiceChange with Restart will be lost, and a command will be received by the MG prior to the receipt of the ServiceChange response.  The MG shall issue error 505 - Command Received before Restart Response".

Does the MG send error 505 if it has not received a restart response from the SENDING MGC, or from ANY MGC?  If the answer is ANY MGC, how does the MG protect itself from being sent commands by unauthorized entities?

Tom Taylor replied:
 

The MG sends 505 to the MGC to which it has sent a ServiceChange registration.  To any other MGC it would send 402 Unauthorized, if it sends anything at all.  I'm not sure it should send anything, because rogue commands could constitute a Denial of Service attack.  Remember that we expect Megaco commands to pass over an established security association (which brings to mind that some day we should add security considerations to the ATM transport annex, Annex I).


From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of Sachin
Sent: Wednesday, July 16, 2008 10:33 AM
To: megaco <at> ietf.org
Subject: [Megaco] Error 402 Unauthorized

Hi,
 
MG has no knowledge of association with the MGC. MGC sends any command to that gateway. The expected reply to this is an error 402. 
 
The MG in the current scenario should not accept any transaction from the MGC. So at what level the error 402 to be sent, is it at transaction level or at the command level.
 
Please help.
 
Thanks
Sachin
IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only.
If you have received this email in error, please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies thereof.
*** eSafe scanned this email for viruses, vandals, and malicious content. ***
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Umut Emin | 17 Jul 18:29 2008
Picon

Endianness question

Hello All,

I have a basic question on binary implementation of MEGACO.

As using ASN.1 data types (BER en/de-coded) with Megaco,
i wonder which byte order[big/little endian] should be followed for the 
content part?

 I have gone through ITU-T X690-0207 doc and RFC 3525 couple
of times without any results. 

Thanx in advance.
Odelia Jacobowitz | 16 Jul 13:06 2008

Isup Megaco Corellation

Hi ,

 

I need to correlate between Isup to Megaco signaling messages ,

Can I expect to find in the ADD request (Megaco message) reference to the cic from the Iam  (Isup message) ?

 

* In the MGCP protocol for instance the cic was encapsulated in the endpoint EI .

Please advice …

Regards,

Odelia Jacobowitz

Embedded Software Engineer

 

Septier Communications Ltd.

Tel :  +972-(0) 3-924-7026 (123)

Fax:  +972-(0) 9-924-7023

Cell:  +972-(0)54-4790-668

Email: odeliay <at> septier.com

Web:  www.septier.com

 

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Christian Groves | 18 Jul 02:10 2008

Re: Isup Megaco Corellation

Hello Odelia,

There is no direct reference to a cic in Megaco. The MGC is expected to 
maintain a mapping between a cic and a TerminationID. So if the MGC 
receives an IAM it will request a particular terminationID based on the 
cic via a ADD.request.

Regards, Christian

Odelia Jacobowitz wrote:
>
> Hi ,
>
> I need to correlate between Isup to Megaco signaling messages ,
>
> Can I expect to find in the ADD request (Megaco message) reference to 
> the cic from the Iam (Isup message) ?
>
> * In the MGCP protocol for instance the cic was encapsulated in the 
> endpoint EI .
>
> *Please advice …*
>
> *Regards,*
>
> *Odelia Jacobowitz*
>
> Embedded Software Engineer
>
> * *
>
> Septier Communications Ltd.
>
> *Tel :* +972-(0) 3-924-7026 (123)
>
> *Fax:* +972-(0) 9-924-7023
>
> *Cell:* +972-(0)54-4790-668
>
> Email: _odeliay <at> septier.com <mailto:odeliay <at> septier.com>_
>
> Web: www.septier.com <BLOCKED::http://www.septier.com>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
>   
Adi AbuAli | 18 Jul 22:29 2008
Picon

Timers Adjustments for H.248 over SCTP

Hi,

I have two questions regarding MEGACO/H.248 timers:

1-Is there any relation between H.248 timers (i.e. MG/MGC Normal execution timer, Pending limit, network delay,..etc), and SCTP timers (i.e RTT, RTO,..etc)?, in other words, reconfigure H.248 timers, will need to readjust the SCTP ones or vice versa?

2-Adittionaly, how come it may happen that H.248 timers for MGC is different than MG ones?, arent such timers need to be synchronized in the registration process or in the Audit command?


Thanks for your help,

Adi AbuAli

CS core optimization engineer

Nokia Siemens Networks UAE

Mobile: +971 55 8502998

E-mail: Adi_abuali <at> yahoo.com

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Maxim Treskin | 25 Jul 19:44 2008
Picon

Digit map syntax question

Hello

I have question about megaco digit map syntax.
Is digitmap, like "([0-9ef])" valid?
I use erlang OTP megaco stack, and it interpretes this digit map that
following numbers is valid:
"0ef", "1ef", "2ef" etc.
Is it right or there is error in megaco stack? I think that valid
number values must be:
"0", "1", "2", ..., "9", "e", "f"

Say me please, which method is right?

--

-- 
Maxim Treskin
Sudhanshu Garg | 25 Jul 20:05 2008

Re: Digit map syntax question

Hi,

Range (two digits separated by hyphen can be expanded into all the digits from first to last (inclusive both ends).
The digits inside square brackets represent the dialled digitmap symbol that can be given at
corresponding place.

So [0-9ef] means [0123456789ef].
Therefore it represents one of the following:
"0", "1", "2", "3", "4", "5", "6", "7", "8", "9","*","#"

Regards,
Sudhanshu.
________________________________________
From: megaco-bounces <at> ietf.org [megaco-bounces <at> ietf.org] On Behalf Of Maxim Treskin [zerthurd <at> gmail.com]
Sent: Friday, July 25, 2008 11:14 PM
To: megaco <at> ietf.org
Subject: [Megaco]  Digit map syntax question

Hello

I have question about megaco digit map syntax.
Is digitmap, like "([0-9ef])" valid?
I use erlang OTP megaco stack, and it interpretes this digit map that
following numbers is valid:
"0ef", "1ef", "2ef" etc.
Is it right or there is error in megaco stack? I think that valid
number values must be:
"0", "1", "2", ..., "9", "e", "f"

Say me please, which method is right?

--
Maxim Treskin
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco

"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 forloss or damage arising from the use of the information
transmitted by this email including damage from virus."
Raphael Tryster | 27 Jul 14:21 2008

Which MGC should be contacted first on retransmission timeout?

 Is there a contradiction between 11.5 and F.3.6?

11.5 says:

"If the MG detects a failure of its controlling MGC, it attempts to
contact the next MGC on its pre provisioned list. It starts its attempts
at the beginning (primary MGC), unless that was the MGC that failed, in
which case it starts at its first secondary MGC".

F.3.6 says:

"When the MG has detected a loss and subsequent re-establishment of
communication with the MGC, the MG sends a ServiceChange Command with a
ServiceChangeMethod of 'Disconnected' to the MGC in the current control
association. If the MGC fails to respond, the MG then sends a
ServiceChange Command with a ServiceChangeMethod of 'Failover' and
ServiceChangeReason 909 ('MGC Impending Failure') to each MGC in its
list in turn until it has successfully established a new control
association, or it has exhausted its list of MGCs".

So, suppose MG sent a Notify and failed to receive a reply before
retransmissions timed out.  According to 11.5, it would send SC to a
DIFFERENT MGC.  According to F.3.6, it would send SC to the SAME MGC,
and only try a different one if the SC also timed out.  Which is it?

I am also puzzled by the language of F.3.6.  ""When the MG has detected
a loss and subsequent re-establishment of communication with the MGC".
Usually, SC Disconnected is sent as a trial to see whether the MGC will
now reply, and not as a result of re-establishment of communication.  Is
some other method of detecting re-establishment of communication being
hinted at here?

Raphael Tryster
**********************************************************************************************
IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the 
named recipient(s) only.
If you have received this email in error, please notify the system manager or the sender immediately and do 
not disclose the contents to anyone or make copies thereof.
*** eSafe scanned this email for viruses, vandals, and malicious content. ***
**********************************************************************************************
Christian Groves | 29 Jul 07:05 2008

Re: Which MGC should be contacted first on retransmission timeout?

Hello Raphael,

In Amendment 1 to H.248.1v3 two notes were added to the F.3.6 text that 
may provide further explanation. The text reads:

      F.3.6 MG Lost Communication

When the MG has detected a loss and subsequent re-establishment of 
communication with the MGC (NOTE 1), the MG sends a ServiceChange 
Command (NOTE 2) with a ServiceChangeMethod of "Disconnected" to the MGC 
in the current control association. If the MGC fails to respond, the MG 
then sends a ServiceChange Command with a ServiceChangeMethod of 
"Failover" and ServiceChangeReason 909 ("MGC Impending Failure") to each 
MGC in its list in turn until it has successfully established a new 
control association, or it has exhausted its list of MGCs. If the MGC 
does respond, the control association continues as if it were not 
interrupted.

NOTE 1: The two main causes for lost communications between the MGC and 
MG are 1) failures or short-term interruptions of the H.248 transport 
connection, or 2) the primary MGC going “OutOfService”. The MG will not 
necessarily be able to discriminate between the two, therefore the 
ServiceChange procedures are the same in both cases.

NOTE 2: The MG may send one or more ServiceChange Commands. The 
transmission of subsequent ServiceChange Commands may be 
timer-controlled. Multiple re-establishment attempts may help in 
situations with short-term failures, either of the transport connection 
or of the MGC, thereby avoiding the invocation of failover procedures 
when they are not warranted.

...

With regards to "Disconnected" despite its name its actually to indicate 
that the Control association was lost and is now re-established, thus 
the first sentence of F.3.6. I don't think there's a problem between 
11.5 and F.3.6 because 11.5 indicates firstly that its already 
determined that the MGC has failed thus the procedure goes into 
failover. In F.3.6 the first part of the procedure is that communication 
is restored and if this isn't successful then go into a failover.
With regards to the "hint" of another method I guess its relying on a 
transport level indication of connectivity between a MGC and MG.

Regards, Christian

Raphael Tryster wrote:
>  Is there a contradiction between 11.5 and F.3.6?
>
> 11.5 says:
>
> "If the MG detects a failure of its controlling MGC, it attempts to
> contact the next MGC on its pre provisioned list. It starts its attempts
> at the beginning (primary MGC), unless that was the MGC that failed, in
> which case it starts at its first secondary MGC".
>
> F.3.6 says:
>
> "When the MG has detected a loss and subsequent re-establishment of
> communication with the MGC, the MG sends a ServiceChange Command with a
> ServiceChangeMethod of 'Disconnected' to the MGC in the current control
> association. If the MGC fails to respond, the MG then sends a
> ServiceChange Command with a ServiceChangeMethod of 'Failover' and
> ServiceChangeReason 909 ('MGC Impending Failure') to each MGC in its
> list in turn until it has successfully established a new control
> association, or it has exhausted its list of MGCs".
>
> So, suppose MG sent a Notify and failed to receive a reply before
> retransmissions timed out.  According to 11.5, it would send SC to a
> DIFFERENT MGC.  According to F.3.6, it would send SC to the SAME MGC,
> and only try a different one if the SC also timed out.  Which is it?
>
> I am also puzzled by the language of F.3.6.  ""When the MG has detected
> a loss and subsequent re-establishment of communication with the MGC".
> Usually, SC Disconnected is sent as a trial to see whether the MGC will
> now reply, and not as a result of re-establishment of communication.  Is
> some other method of detecting re-establishment of communication being
> hinted at here?
>
> Raphael Tryster
> **********************************************************************************************
> IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the 
> named recipient(s) only.
> If you have received this email in error, please notify the system manager or the sender immediately and do 
> not disclose the contents to anyone or make copies thereof.
> *** eSafe scanned this email for viruses, vandals, and malicious content. ***
> **********************************************************************************************
>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
>
>   

Gmane