Subject: RE: [Megaco] Service Change with Disconnect

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 5 Apr 2006 04:07:08 -0400

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: Wainwright, John (Com US) [mailto:[email-masked]] 
Sent: Tuesday, April 04, 2006 5:24 PM
To: [email-masked]
Subject: [Megaco] Service Change with Disconnect

Assuming I have a valid association between an MG & MGC using a
negotiated Version=2 and port = 20000.  Messages from the MG to MGC
start failing/timing out so the MG starts sending a Service Change
message with Method = Disconnected.  Should this use Reason code 907 ?

[KJBII] 907 is used to explain why the MG is going out of service with
Forced or Graceful.  900 ("Service Restored") is appropriate for
Disconnected.  Remember that Disconnected indicates that the control
association has been reestablished.

If after some time the MGC responds and re-establishes the connection
should the Megaco version number and Port number used for this
association be by default the same as when the original connection was
established or should they be re-negotiated as if the previous
association had never existed ?

[KJBII] If the version/MGCID/version/etc. are not explicitly
renegotiated as part of the reestablishment of the control association,
then they should be assumed to remain as they are.  Note that in the
instance where the MG goes to a new secondary MGC these items will
probably have to be renegotiated.

Thanks
John

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

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

---

From: "B Venkat S.R Swamy" <[email-masked]>
Date: Wed, 5 Apr 2006 14:40:14 +0530

Hi

A related query to the issue raised is:

Scenario:

>The transport between MG and MGC is UDP.

> MGC-MG are in control association, with Version negotiated as 2.

> MGC goes down and loses all its call and termination data.

> MG keeps sending ServiceChange with Disconnected method to MGC, with Message header ID(MID) as 2.

> MGC comes up again and receives the ServiceChange with Disconnected method as the first message, with MID as 2.

Query:

Should MGC accept the ServiceChange with Disconnected method, received with MID as 2 and reestablishes the association. The version for the re-established association shall be 2. Servicechange reason could be "900", "916" or "917". Would be useful in scenario where MGC keeps minimal information at its ends and can rebuild its context by doing the Audit procedures.

OR

Should it reject the Disconnected message since it was expecting ServiceChange command with "Restart" method and MID as 1

OR

It is protocol independant and depends on the particular implementation.

Some more queries:

> Is 909 "MGC Impending Failure" ServiceChange reason valid with Disconnected method.

> Whether the MG behaviour remains same with regard to servicechange reason "900" in the above scenario, independant of the transport mechanism used(TCP(or any connection oriented protocol) or UDP).

Clarifications to above queries in the protocol will would really help in resolving Interoperability issues which otherwise could arrive.

regards

B Venkat S.R Swamy

Senior Technical Leader

Flextronics Software Systems

Phone: +91-124- 4176213

Fax: +91-124-4300247

web: www.flextronicssoftware.com

"Kevin Boyle" <[email-masked]>

"Kevin Boyle" <[email-masked]>

04/05/2006 01:37 PM

To

"Wainwright, John \(Com US\)" <[email-masked]>, <[email-masked]>

cc

Subject

RE: [Megaco] Service Change with Disconnect

Comments inline. [KJBII]

Kevin

-----Original Message-----

To: [email-masked]

Thanks

John

Megaco mailing list

[email-masked]

Megaco mailing list

[email-masked]

*********************** FSS-Restricted ***********************

"DISCLAIMER: This message is proprietary to Flextronics Software

Systems Limited (FSS) 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. FSS accepts no responsibility for

loss or damage arising from the use of the information transmitted

by this email including damage from virus."

---

From: [email-masked]
Date: Wed, 5 Apr 2006 12:39:18 +0200

I'm tending to the 2nd option, rejecting the SC.request by the MGC with an
"appropriate" error code.

But I guess that such an error code is missing so far (guess this specific
use case wasn't considered yet; neither #502 nor #530 seems to be fitting).
Guess we need sth like "MGC was temporarily out-of-service" or "MGC loss of
data" ...

Albrecht

                      "B Venkat S.R Swamy"                                                                                               
                      <b.swamy@flextronicsso         To:      "Kevin Boyle" <[email-masked]>                                          
                      ftware.com>                    cc:      [email-masked]                                                            
                                                     Subject: RE: [Megaco] Service Change with Disconnect                                
                      05.04.2006 11:10                                                                                                   

Hi

Scenario:
> MGC comes up again and receives the ServiceChange with Disconnected
method as the first message, with MID as 2.

Query:
Should MGC accept the ServiceChange with Disconnected method, received with
MID as 2 and reestablishes the association. The version for the
re-established association shall be 2. Servicechange reason could be "900",
"916" or "917". Would be useful in scenario where MGC keeps minimal
information at its ends and can rebuild its context by doing the Audit
procedures.

OR

Should it reject the Disconnected message since it was expecting
ServiceChange command with "Restart" method and MID as 1

OR

Some more queries:
> Whether the MG behaviour remains same with regard to servicechange reason
"900" in the above scenario, independant of the transport mechanism
used(TCP(or any connection oriented protocol) or UDP).

Clarifications to above queries in the protocol will would really help in
resolving Interoperability issues which otherwise could arrive.

regards
B Venkat S.R Swamy
Senior Technical Leader
Flextronics Software Systems
Phone: +91-124- 4176213
Fax: +91-124-4300247
web: www.flextronicssoftware.com
(Embedded image moved to file: pic30946.gif)"Kevin Boyle"
<[email-masked]>

                         "Kevin                                            
                         Boyle"                                            
                         <kboyle                                           
                         @nortel (Embedded image moved to file:            
                         .com>   pic27089.gif)                             
                                                                        To 
                                         (Embedded image moved to file:    
                         04/05/2         pic00766.gif)                     
                         006             "Wainwright, John \(Com US\)"     
                         01:37           <[email-masked]>,    
                         PM              <[email-masked]>                 
                                 (Embedded image moved to file:            
                                 pic00148.gif)                             
                                                                        cc 
                                         (Embedded image moved to file:    
                                         pic02063.gif)                     
                                 (Embedded image moved to file:            
                                 pic32209.gif)                             
                                                                   Subject 
                                         (Embedded image moved to file:    
                                         pic31519.gif)                     
                                         RE: [Megaco] Service Change with  
                                         Disconnect                        

                                 (Embedded image moved to file:            
                                 pic05505.gif)                             
                                          (Embedded image moved to file:   
                                          pic19636.gif)                    

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: Wainwright, John (Com US) [mailto:[email-masked]]
Sent: Tuesday, April 04, 2006 5:24 PM
To: [email-masked]
Subject: [Megaco] Service Change with Disconnect

Thanks
John

by this email including damage from
virus."_______________________________________________