Subject: [Megaco] Service Change with Disconnect

From: "Wainwright, John \(Com US\)" <[email-masked]>
Date: Tue, 4 Apr 2006 14:23:37 -0700

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 ?
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 ?

Thanks
John

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 6 Apr 2006 10:10:47 -0400

Forwarding to the list, as I mistakenly left it off the distribution.

________________________________

From: Boyle, Kevin [NCRTP:3Z40:EXCH] 
Sent: Thursday, April 06, 2006 10:08 AM
To: 'B Venkat S.R Swamy'
Subject: RE: [Megaco] Service Change with Disconnect

More comments inline. [KJBII]
 
Kevin

________________________________

	From: B Venkat S.R Swamy
[mailto:[email-masked]] 
	Sent: Thursday, April 06, 2006 8:11 AM
	To: Boyle, Kevin [NCRTP:3Z40:EXCH]
	Cc: [email-masked]; [email-masked]; Stephen Mell
	Subject: RE: [Megaco] Service Change with Disconnect

	Hi
	
	please find the comments inline[BVS]
	
	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/06/2006 05:16 PM

To

B Venkat S.R Swamy/HSS@HSS, "Stephen Mell" <[email-masked]>	

cc

[email-masked], [email-masked]	

Subject

RE: [Megaco] Service Change with Disconnect	

	Since Disconnected implies that the control association is being
	reestablished, I believe that the MG should use the version from
the
	control association it is attempting to reestablish.  At that
time, it
	is free to attempt to renegotiate the protocol version.
	
	[BVS] There is no doubt that MG would send the Disconnected
method with the version same as
	control association it is retrying to re-establish. However
renegotiating the protocol version
	with Disconnected method is something which is not mentioned in
the protocol. Version and 
	profile negotiation happens only with Restart, Failover and
Handoff as mentioned in Annex F 3.1 and 3.2
	[/BVS]
	[KJBII] You are right.  There is no renegotiation of version
with Disconnected... a slip of the fingers on my part. 

	Why, exactly, would an MG reject a Handoff to the same MGCID?
If the
	MGCID is the same then it appears to me that the MG ought to
accept that
	Handoff and establish a new control association to the MGC.  I
don't
	understand your implication here with regards to the mID.
	
	[BVS]I am sorry, I meant version field in the message header. I
am rephrasing the statement again
	"there is fair possibility that MG might not accept the
	ServiceChange with Handoff and its own MGCId, if the version
field in the message header
	is other than Disconnected message.
	[/BVS]
	[KJBII] This is correct.  The SC Handoff would be within the
context of the control association, and so must conform to the
negotiated version of that association.  So the version would have to be
the same.  The MG would revert to V1 messaging for the subsequent
re-registration, and which time it could renegotiate the version (which
is what I was thinking about when I made my error above).

	Kevin

	________________________________
	
	From: B Venkat S.R Swamy
	[mailto:[email-masked]] 
	Sent: Thursday, April 06, 2006 1:39 AM
	To: Stephen Mell
	Cc: [email-masked]; [email-masked]
	Subject: RE: [Megaco] Service Change with Disconnect

	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 
	
	it shouldn't issue it under these circumstances. 

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

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

	(See attached file: graycol.gif)
	(See attached file: ecblank.gif)
	_______________________________________________
	Megaco mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/megaco

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