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

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

At 07:21 AM 3/3/2003, [email-masked] wrote:

>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

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

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 04 Mar 2003 11:00:52 -0500

Hi,

It would be nice to have "Blocking/Unblocking" and "Metering Pulse"
packages in manyfolks CAS draft since they are common to CAS.

Regarding B11- B15. I understand that everything can be extended
in extension packages, but specifically for this case I think they
should be present in "base" R2 package since they present in
corresponding "base" definition of R2 Q.411

More over since there is enormous number of different R2 variants
(well, at least one for each country) I think it is not feasible to have
an extension package for each variant. I think in this case it would
be much better to have "base" R2 package that can cover as much
as it can. And since we know that meaning of a specific R2 signal
is unique (that is not ambiguous) in any given R2 variant it is safe
to have all spare/unused signals in base R2 package and let the
call agent deal with the meaning of the signal. More over the R2
package can have an appendix which will define the meanings for
a specific variant (just for reference).

Thus I think that "base" R2 package should define signals/events
without specific variant in mind using as much generic meaning
as possible for R2 signals. Then MGC can map them to a specific
meaning depending on R2 variant in use. If necessary the draft
can define R2 extension packages which will define meaning of
the R2 signals in similar way it is defined for current r2 package.
For example, draft can define r2-itu package with explicit parameter
values which will correspond to ITU definition of these values.

With all that said it also seems that the base R2 package should have
a read only property (per termination) which lists variants currently
supported/loaded, or maybe better yet it should have two properties.
One (read only) property will list all variants a termination can support
and another (read/write) property will allow to set the variant to be
used for a termination.

IANA registry can be used for a specific values of R2 variants.

Thanks.
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 04 Mar 2003 11:00:52 -0500

Hi,

Thanks.
         Aleks