Subject: RE: [Megaco] Service Change with Disconnect

From: "Stephen Mell" <[email-masked]>
Date: Wed, 5 Apr 2006 17:43:31 +0100

Hi,

One strategy might be to refuse the SC {Method=Disconnected} with an 
arbitary reason and then 

force the MG to re-register by issuing a ServiceChange=Handoff, giving its 
own MGCId?

The MGC can issue such a Service Change after a "transparent" MGC 
failover, so I don't see why 

it shouldn't  issue it under these circumstances.

Steve 

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

---

From: "B Venkat S.R Swamy" <[email-masked]>
Date: Thu, 6 Apr 2006 11:09:08 +0530

Hi

so far we received multiple views on this issue and that's exactly is the concern,

protocol should clearly identify such scenarios so that we can have consistent implementations across different vendors and

there is least interop issues.

BTW, in the solution suggested by you, what should be the version in the Message Header ID(MID),

should it be 1, OR

the MID received in the ServiceChange, with Disconnected method received from MG.

there is fair possibility that MG might not accept the ServiceChange with Handoff and its own MGCId, if the MID is other than Disconnected message.

as per the Annex F, F.3.8(MGC Initiated MG Re-Registration ), the messsage is sent by MGC in the same control association(with version already negotiated)

so that the MG can re-register again and version and profile negotiation takes place in re-registration.

regards

B Venkat S.R Swamy

Senior Technical Leader

Flextronics Software Systems

Phone: +91-124- 4176213

Fax: +91-124-4300247

web: www.flextronicssoftware.com

"Stephen Mell" <[email-masked]>

"Stephen Mell" <[email-masked]>

04/05/2006 10:13 PM

To

[email-masked]

cc

[email-masked]

Subject

RE: [Megaco] Service Change with Disconnect

Hi,

One strategy might be to refuse the SC {Method=Disconnected} with an arbitary reason and then

force the MG to re-register by issuing a ServiceChange=Handoff, giving its own MGCId?

The MGC can issue such a Service Change after a "transparent" MGC failover, so I don't see why

Steve _______________________________________________

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."