Subject: [Megaco] C-294: H.248.RA Re-answer package

From: "Schwarz Albrecht" <[email-masked]>
Date: Thu, 21 Jun 2007 14:46:57 +0200

Hi QianPengqing & XieBaoguo!

In order to save meeting time, just some basic questions in advance
(because I'm not familiar with that supplementary service):

Q1: Is the "re-answer call" a standardized PSTN (or even ISDN)
supplementary service? For public/private networks?
International/national?

Q2: What is the benefit (for party B? for party A?) for the on-hook and
possible subsequent off-hook actions by party B?
I don't think that this has any impact on (reduced?) charging. Right?

Q3: Is this supplementary service already activated during call
establishment?

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

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Fri, 22 Jun 2007 11:42:12 +0200

Thanks for reply!
Concerning A2: "no rights to interrupt the call" -> does this mean that
party B is not allowed to release the call, i.e. such a call may be only
finally released by A?

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Freitag, 22. Juni 2007 06:42
To: Schwarz Albrecht
Cc: [email-masked]; [email-masked]
Subject: Answer: C-294: H.248.RA Re-answer package

Answer to Schwarz Albrecht: 

A1: Yes, it is a national standardized PSTN supplementary service (for
example, it's sepcified in telecommunication standard (GF002-9002) of
China), and can be applied to public or private networks. 

A2: The "re-answer call" is for some typical application, for example,
the party A may be an operator or advanced user, and the party B has no
rights to interrupt the call by on-hook action, and the party B may
perform the off-hook action to recover the session after the possible
previous on-hook action, or wait till the party A hooks on. 

Yes, it has no impact on charging. 

A3: Yes. 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail
is solely property of the sender's organization. This mail communication
is confidential. Recipients named above are obligated to maintain
secrecy and are not permitted to disclose the contents of this
communication to others.
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
originator of the message. Any views expressed in this message are those
of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: [email-masked]
Date: Fri, 22 Jun 2007 12:41:58 +0800

In order to save meeting time, just some basic questions in advance 
(because I'm not familiar with that supplementary service):
Q1: Is the "re-answer call" a standardized PSTN (or even ISDN) 
supplementary service? For public/private networks? 
International/national?
A1: Yes, it is a national standardized PSTN supplementary service (for 
example, it's sepcified in telecommunication standard (GF002-9002) of 
China), and can be applied to public or private networks.
Q2: What is the benefit (for party B? for party A?) for the on-hook and 
possible subsequent off-hook actions by party B?
A2: The "re-answer call" is for some typical application, for example, the 
party A may be an operator or advanced user, and the party B has no rights 
to interrupt the call by on-hook action, and the party B may perform the 
off-hook action to recover the session after the possible previous on-hook 
action, or wait till the party A hooks on.
I don't think that this has any impact on (reduced?) charging. Right? 
Yes, it has no impact on charging.
Q3: Is this supplementary service already activated during call 
establishment? 
A3: Yes.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 26 Jun 2007 15:14:17 -0400

I don't see the need for this package.  Why can't the MGC just look for
the offhook (or seize, or other appropriate event) and reconnect the
call?  The MG isn't allowed to disconnect calls without MGC command, so
I can't see how this is a problem.
 
Kevin

From: Schwarz Albrecht [mailto:[email-masked]] 
Sent: Friday, June 22, 2007 5:42 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Megaco] RE: Answer: C-294: H.248.RA Re-answer package

Thanks for reply!

A3: Yes.

---

From: [email-masked]
Date: Wed, 27 Jun 2007 08:46:58 +0800

The "re-answer" signal is sometimes different from the "answer" signal or 
any other signals defined in H.248, e.g. it has a different code of "abcd" 
bits, so we should report it to the MGC as a different event, and this 
also makes the intention of the party B clear.

"Kevin Boyle" <[email-masked]> 
2007-06-27 03:14

收件人
"Schwarz Albrecht" <[email-masked]>, 
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
RE: [Megaco] RE: Answer: C-294: H.248.RA Re-answer package

I don't see the need for this package.  Why can't the MGC just look for 
the offhook (or seize, or other appropriate event) and reconnect the call? 
 The MG isn't allowed to disconnect calls without MGC command, so I can't 
see how this is a problem.
 
Kevin

Thanks for reply!

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: [email-masked]
Date: Wed, 27 Jun 2007 09:16:19 +0800

收件人

Kevin

Thanks for reply!