Re: sendRecv and busy tone on physical termination in the sametime

Actually, now that I think about it, the statement that Mode does not
affect Signals is in 7.1.7, LocalControl Descriptor rather than 7.1.11,
Signals Descriptor.  Sorry for the confusion.

Kevin 

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Boyle, Kevin (NCRTP:0Q10)
Sent: Friday, August 01, 2008 12:10 PM
To: Deepak Bissa; Maxim Treskin; [email protected]
Subject: Re: [Megaco] sendRecv and busy tone on physical termination in
the sametime

Comments inline (to both emails in the thread). [KJBII]

Kevin 

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Deepak Bissa
Sent: Thursday, July 31, 2008 3:05 AM
To: Maxim Treskin; [email protected]
Subject: Re: [Megaco] sendRecv and busy tone on physical termination in
the sametime

Hello,
In my view, MGC should set the mode to Inactive if it wants to play busy
tone. MGC was not able to complete the requested session and applied
busy tone. In such circumstances there is no need for keeping the
resources allocated at MG for the session.

[KJBII] The MGC doesn't have to do anything.  It appears that you are
equating busy tone with some kind of call processing error condition.
This is not the only application of busy tone, and is an extremely
unwise assumption.  MGs *must not* make assumptions about call
processing functionality and must do as they are commanded insofar as
possible.

However, I would like to know the specific scenario where MGC is setting
the mode to send/receive and applying busy tone in same packet.

[KJBII] This is irrelevant.  The MG MUST set the Mode to SR *and* must
play out busy tone as requested.  Keep in mind that per 7.1.11 Mode has
no effect on Signals anyway.

For second part of the query, as per protocol H.248.1 (V3) section 7.2:
" The descriptors shall be processed in the order in which they appear".
So, the media descriptor containing mode as send/receive and signal
descriptor for application of busy tone should be processed in order of
their appearance in the command.

[KJBII] While this is indeed true, the fact is that such a command is
not illegal, and must be followed.  The MG cannot possibly know what is
leading the MGC to perform this action.  All it can do is what it is
told to do: set Mode to SR and apply busy tone.  The two are not
mutually exclusive.

With regards,
Deepak Bissa

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Maxim Treskin
Sent: Wednesday, July 30, 2008 10:48 PM
To: [email protected]
Subject: [Megaco] sendRecv and busy tone on physical termination in the
sametime

Hello

Is it normal, when MGC sends me signal cg/bt and termination mode
send/receive in the same packet?

[KJBII] If by "normal" you mean "syntactically legal", then yes.  If you
mean "a valid call processing function" that would depend upon the
scenario, the operating region and a number of other variables that are
up to the judgment of the MGC.

Which behaviour must be realised on this termination: switch TDM port of
termination to RTP or signal to it busy?

[KJBII] The MG must perform both actions.

Thank you
--
Maxim Treskin
_______________________________________________
Megaco mailing list
[email protected]
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."
_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco