Subject: [Megaco] draft-ietf-megaco-r2package-03.txt : Difference from previous revision

From: [email-masked]
Date: Mon, 3 Mar 2003 17:51:41 +0530

Changes between version 03 over version 02 of R2 package

1. Changed the wording of Abstract section.

2. Changed the wording of Introduction section to reflect that R2 package is
derived package of bcas package. Also, it touches upon the new signal and event
"r2addr" which is added in this derived r2 package.

3. Rephrased assumption b) in Assumptions section (section 5).

4. Corrected sequence numbering of 4th assumption to d) in Assumptions section
(section 5)

5. Section 6.1: R2 package definition modified so as to extend bcas package.
Changed the wording in description so as to clarify that R2 package extends
bcas. Version 02 advocated it being used in conjunction with bcas package.

6. Section 6.2
 - Removed property "clear back signal validation time"
 - Changed Property Id from "callen" to "snl" for Property Name "Source Number
Length"
 - Removed the wordings mentioning the procedure to collect source number.
 - Removed property "source number time-out"
 - Removed property "subscriber line status flag"
 - Removed property "trunk direction"
 - Added property "Compelling Sequence Keepalive Timer"

7. Section 6.3
 - Removed event "Unblock"
 - ObservedEventDescriptor of r2addr event
  + Changed description for possible values of dimeth parameter
  + Removed procedure for collecting source number in si parameter description
  + Added parameter "Source Number Termination Method"
  + Changed description of sc parameter to align the language used throughout
  + Changed description of es parameter to align the language used throughout
  + Changed description of cc parameter to align the language used throughout
  + Removed procedure for collecting country code in cc parameter description
  + Changed description of disc parameter to align the language used throughout
  + Changed description of nac parameter to align the language used throughout
 - Renamed "Subscriber Line Status" to "Called Party Reachability Status" to
clarify the meaning for the event
 - Changed the wording in R2 Failure event description. Also, changed the
possible value for this event
 - Changed description for possible values of dimeth parameter under
ObservedEventDescriptor of di event.
 - Changed description si parameter under ObservedEventDescriptor of si event.
 - Added Source Number Termination method parameter under
ObservedEventDescriptor of si event
 - Added Congestion Event

8. Section 6.4
 - Removed Block signal
 - Removed Unblock signal
 - Renamed signal "Subscriber Line Status" to "Called Party Reachability
Status". Also, modified the description for this signal

9. Section 6.5
 - Removed Call Duration statistics defined by this package.

10. Section 7
 - Removed description of property parameters defined in section 7.1 of version
02
 - Removed procedures for exchanging supervisory signals
 - Removed procedures for exchanging call set-up control information
 - Removed call flows for incoming MG
 - Removed call flows for outgoing MG
 - Added procedure for Termination of Called Party Number digit collection at
incoming MG
 - Added procedure for Termination of Calling Party Number collection at
incoming MG
 - Added procedure for Termination of Country Code digit collection at incoming
MG
 - Added procedure for Termination of Compelling Sequence

11. Section 8
 - Modified reference number [4] for newer version of bcas draft referred

12. Section 9
 - Modified Author's Address to reflect new contact phone numbers

13. The usage of keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" are corrected all
across the draft.

Thanks
- Vikram Nair
www.hssworld.com

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) 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. HSS accepts
no responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus.

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

---

From: [email-masked]
Date: Tue, 4 Mar 2003 12:47:37 +0530

Aleks,

Response inline [Kushanava]

regards,
Kushanava

Aleksandr Ryabin <[email-masked]> on 03/03/2003 10:43:20 PM

To:   Vikram Nair/HSS@HSS, [email-masked]
cc:   Kushanava Laha/HSS@HSS

Subject:  [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference from
      previous revision

Hi,

These are pretty big changes. I know the previous version was a draft,
but its been out there for a while now, so there are implementations
which use it. That seem to be a good reason to bump the version
of the package for new revision of draft.

[Kushanava] The previous R2 package version had its limitations as pointed
out by this mailing list. Moreover there was a strong urge to align
it with the "bcas" package and make "r2" package a derived package of
"bcas". We believe the suggestions were valid and this new revision
was inevitable. We had waited this long for "bcas" to become an RFC,
so that there is a stable "bcas" package version which "r2" can derive.
But till now we still await the standardization of "bcas".

Questions:

1. Now that block/unblock signals/events have been removed I'd think
bcas package should be handling these supervisory signal procedures,
but I can't seem to find any reference to these procedures in bcas.
Can you clarify on how block/unblock are to be implemented now?

[Kushanava] CAS Trunk Blocking/Unblocking is not specific to R2. Again
it may not be mandatory for all CAS signaling to realize trunk blocking/
unblocking procedures. So "bcas" may not be the right place for it.
Neither is "r2". A separate package draft ("casmntc") has been submitted
to IETF to this effect. I am expecting it to be out within the next few days.

2. I can't seem to find a way to send/receive to/from MGC (currently spare) R2
Group B backward digits from B-11 to B-15?
One way would be to have them in possible values of cplc and their
descriptions
specified as "spare B-xx". Another way would be to add "Spare Called Party
Line Condition Value" parameter to cprs event and signal with int value equal
of the B signal received/to send.

[Kushanava] The advised solution to this is to extend this R2 package and
introduce new enums for "cplc". This could be true even for parameters other
than "cplc" where variants have a role to play. I anticipate a derived
r2 package for each variant that has something different to offer. This R2
package offers the basic skeleton to move forward towards implementing
variant peculiarities, if not already covered by this package.

3. I can't seem to find a way to implement "Metering Pulse" procedure defined
for some R2 variants using ether bcas or R2 packages? For example, one
of the definitions of such a pulse is a "seizure ack" pulse from a terminating
end on a circuit in connected/answer state.

[Kushanava] Metering is not specific to R2. It may be present in any CAS
signaling. Moreover not all flavours of R2 permit metering to be mandatory.
There should be therefore a general philosophy of attacking this problem
common to all CAS signaling. The solution should be sensitive to
a) Realizing that MGC is the master for collecting and generating charging
information
b) Interworking of the CAS "metering pulse" signals with other signaling
(both PDN and PSTN)
c) Optimizing the network traffic if metering information is transported to
and fro between MGC and MG
d) Latency, if metering information is transported to and fro between MGC
and MG
We are working towards a separate package that addresses this issue.
Any suggestions?

Thanks
         Aleks