RE: FW: IPCDN Digest, Vol 15, Issue 16
"Eugene Nechamkin" <[email protected]> Thu, 1 Sep 2005 21:00:36 -0700
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <24CDBA67F085904999751B3C4F9E8C0B031230FB@NT-RMNA-0740.brcm.ad.broadcom.com> |
Phil,
I agree with your approach to modify two objects - Min and Max with the
following comment:
ETSI EN 300 001 V1.5.1 spec defines the break period (which is an equivalent
for flash) as being as low as 50ms (Table 9.1.1). As a reality check - we
have seen some European requests for having the flash range starting from
50-100ms. Hence, I would think that the lower range of 20 msec for both
objects would have a better chance to meet the various requirements in the
field. The following objects definitons seem to be satisfactory from our
prospective:
pktcNcsEndPntConfigMinHookFlash OBJECT-TYPE
SYNTAX Unsigned32 (20..1550)
.....
DEFVAL (300)
pktcNcsEndPntConfigMaxHookFlash OBJECT-TYPE
SYNTAX Unsigned32 (20..1550)
.....
DEFVAL (1100)
Eugene.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Freyman Phillip-FPF300
Sent: Thursday, September 01, 2005 7:14 AM
To: '[email protected]'
Subject: [ipcdn] FW: IPCDN Digest, Vol 15, Issue 16
Eugene,
Thank you for reviewing the GR 506 document however, I do not fully agree
with your proposal.
Per your email, GR 506 states:
Table 12-2. Flash Response Enabled Timing On-Hook Duration (milliseconds)
SPCS Interpretation
< 200 Hit
200 to 300 Hit or Flash
300 to 1100 Flash
1100 to 1550 Flash or Disconnect
>1550 Disconnect
This implies that the network MUST accept 300 to 1100 milliseconds as hook
flash and must NOT accept less than 200 ms or more than 1550 ms.
The ranges of 200 to 300 and 1100 to 1550 are ranges where the network may
accept or may reject the timing.
I do agree that some changes may be appropriate in the ranges of min/max
values..
I do not agree with your proposed max default value and propose the following
to bring the SigMIB into alignment with GR 506.
Current rev8 text:
pktcNcsEndPntConfigMinHookFlash OBJECT-TYPE
SYNTAX Unsigned32 (20..1000)
UNITS "Milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This is the minimum time a line needs to be on hook for a
valid hook flash. The value of this object MUST be
greater than the value of
pktcNcsEndPntConfigPulseDialMaxBreakTime. The value of
pktcNcsEndPntConfigMinHookFlash MUST be less than
pktcNcsEndPntConfigMaxHookFlash. This object MUST only be
set via the configuration file during the provisioning
process.
Furthermore, given the possibility for the 'pulse dial'
and 'hook flash' to overlap, the value of this object MUST
be greater than the value contained by the MIB Object
pktcNcsEndPntConfigPulseDialMaxMakeTime."
DEFVAL { 300 }
::= { pktcNcsEndPntConfigEntry 32 }
pktcNcsEndPntConfigMaxHookFlash OBJECT-TYPE
SYNTAX Unsigned32 (20..1000)
UNITS "Milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This is the maximum time a line needs to be on hook for a
valid hook flash. The value of
pktcNcsEndPntConfigMaxHookFlash MUST be greater than
pktcNcsEndPntConfigMinHookFlash. This object MUST only be
set via the configuration file during the provisioning
process."
DEFVAL { 800 }
::= { pktcNcsEndPntConfigEntry 33 }
Proposed rev8 text change:
pktcNcsEndPntConfigMinHookFlash OBJECT-TYPE
SYNTAX Unsigned32 (200..1550)
UNITS "Milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This is the minimum time a line needs to be on hook for a
valid hook flash. The value of this object MUST be
greater than the value of
pktcNcsEndPntConfigPulseDialMaxBreakTime. The value of
pktcNcsEndPntConfigMinHookFlash MUST be less than
pktcNcsEndPntConfigMaxHookFlash. This object MUST only be
set via the configuration file during the provisioning
process.
Furthermore, given the possibility for the 'pulse dial'
and 'hook flash' to overlap, the value of this object MUST
be greater than the value contained by the MIB Object
pktcNcsEndPntConfigPulseDialMaxMakeTime."
DEFVAL { 300 }
::= { pktcNcsEndPntConfigEntry 32 }
pktcNcsEndPntConfigMaxHookFlash OBJECT-TYPE
SYNTAX Unsigned32 (200..1500)
UNITS "Milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This is the maximum time a line needs to be on hook for a
valid hook flash. The value of
pktcNcsEndPntConfigMaxHookFlash MUST be greater than
pktcNcsEndPntConfigMinHookFlash. This object MUST only be
set via the configuration file during the provisioning
process."
DEFVAL { 1100 }
::= { pktcNcsEndPntConfigEntry 33 }
Regards,
Phil
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Wednesday, August 31, 2005 11:08 AM
To: [email protected]
Subject: IPCDN Digest, Vol 15, Issue 16
Send IPCDN mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://www1.ietf.org/mailman/listinfo/ipcdn
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific than "Re:
Contents of IPCDN digest..."
Today's Topics:
1. RE: draft-ipcdn-pktc-signaling-08, further changes;result of
conference call (Eugene Nechamkin)
----------------------------------------------------------------------
Message: 1
Date: Tue, 30 Aug 2005 18:44:56 -0700
From: "Eugene Nechamkin" <[email protected]>
Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further
changes;result of conference call
To: "Sumanth Channabasappa" <[email protected]>
Cc: [email protected]
Message-ID:
<24CDBA67F085904999751B3C4F9E8C0B031230A3@NT-RMNA-0740.brcm.ad.broadcom.com>
Content-Type: text/plain; charset=iso-8859-1
Sumanth,
Looking further at the Bellcore specs for pulse flash requirements
(GR-506-CORE "LSSGR: Signaling for Analog Interfaces"), it turnes out that
the requirements for the pulse range for flash are higher than it is
currently allowed by the "pktcNcsEndPntConfigMaxHookFlash" MIB Object.
Bellcore specs say that flash MUST be 300-1100, but may be up to 1550:
Table 12-2. Flash Response Enabled Timing On-Hook Duration (milliseconds)
SPCS Interpretation
< 200 Hit
200 to 300 Hit or Flash
300 to 1100 Flash
1100 to 1550 Flash or Disconnect
>1550 Disconnect
To better meet the Bellcore specs requirements, the following modification of
the MIB Object's range is proposed:
pktcNcsEndPntConfigMaxHookFlash OBJECT-TYPE
SYNTAX Unsigned32 (20..1550)
UNITS "Milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This is the maximum time a line needs to be on hook for a
valid hook flash. The value of
pktcNcsEndPntConfigMaxHookFlash MUST be greater than
pktcNcsEndPntConfigMinHookFlash. This object MUST only be
set via the configuration file during the provisioning
process."
DEFVAL { 800 }
::= { pktcNcsEndPntConfigEntry 33 }
.
-----Original Message-----
From: Sumanth Channabasappa [mailto:[email protected]]
Sent: Friday, August 26, 2005 7:24 AM
To: Jean-Francois Mule
Cc: [email protected]; Freyman Phillip-FPF300; Eugene Nechamkin; David De Reu;
T, Shivakumar; [email protected]; Satish Kumar at Texas Instruments; Beacham
Gordon-CGB005
Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result of
conference call
Jean-Francois,
I concur. Unless there are objections, I will be presenting the final
proposal to this group in the next week.
Regards
Sumanth
-----Original Message-----
From: Jean-Francois Mule
Sent: Friday, August 26, 2005 7:18 AM
To: Sumanth Channabasappa
Cc: [email protected]; 'Freyman Phillip-FPF300'; 'Eugene Nechamkin'; 'David De
Reu'; 'T, Shivakumar'; '[email protected]'; Satish Kumar at Texas
Instruments; 'Beacham Gordon-CGB005'
Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result of
conference call
Sumanth,
Thanks for inviting anyone from IETF ipcdn to attend the discussion and
for the notes.
We have not seen one comment on your posting in 15 days so the proposal
should be good enough. Per the IETF#63 meeting, the action item on the
signaling MIB was: # AI: authors to close one open issue on tone table by
August 20. # Ask Randy to review final proposal.
Can you put out the proposed changes in the form of updated object
definitions to the list so we can see all the aggregated changes?
Based on our discussions, we are getting close to the end on this one and I
would like to set the date of next Friday, September 2nd to have a consensus
on the technical changes to allow a draft09 publication by mid-September at
the latest.
Thanks,
Jean-François
> -----Original Message-----
> From: Sumanth Channabasappa
> Sent: Wednesday, August 10, 2005 10:09 AM
> To: [email protected]
> Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result
> of conference call
>
> Folks,
>
> As per the discussion on the conference call today (thanks to the
> attendees), the proposal from Phil seems to be reasonable.
>
> Further, there was a suggestion to include the following examples in
> the draft for clarity and ease of implementation. Note: Example B was
> also the cause for the latest suggestion.
>
>
> Example A: Call waiting tone defined per ITU-T E.180:
> 1) 400 Hz AM modulated by 16 Hz, on for 500ms at -4 dBm
> 2) 400 Hz AM modulated by 16 Hz, off for 400ms
> 3) 400 Hz not AM modulated, on for 50 ms at -4 dBm
> 4) 400 Hz not AM modulated, off for 450 ms
> 5) 400 Hz not AM modulated, on for 50 ms at -4 dBm
> 6) 400 Hz not AM modulated, off for 3450 ms
> 7) 400 Hz not AM modulated, on for 50 ms at -4 dBm
> 8) 400 Hz not AM modulated, off for 450 ms
> 9) 400 Hz not AM modulated, on for 50 ms at -4 dBm
> 10) 400 Hz not AM modulated, off for 3450 ms
> 11) not repeated, not continuous
>
> Assume userDefined1(17) is assigned to this tone:
>
> ToneType|Freq-1|Freq-2|Freq-3|Freq-
> 4|FreqMode|ModePrtg|DbLevel|OnDur|Off
> Dur|Rep-Count
> ======================================================================
> ==
> =============
> 17 400 16 0 0 1 90 -40 500
> 400 0
> 17 400 0 0 0 2 0 -40 50
> 450 0
> 17 400 0 0 0 2 0 -40 50
> 3450 0
> 17 400 0 0 0 2 0 -40 50
> 450 0
> 17 400 0 0 0 2 0 -40 50
> 3450 0
>
>
> pktcSigDevToneTable:
> ToneType|ToneRep-Count|Steady
> ================================
> 17 0 false(2)
>
>
> ----------------------------------------------------------------------
> --
> ---------------
>
> Example B - Congestion Tone - congestion(17):
>
> This example of an embedded cadence is based on an operator variation.
> 1) 400Hz on for 400ms -10 dBm
> 2) 400Hz off for 350ms
> 3) 400Hz on for 225ms -4 dBm
> 4) 400Hz off for 525ms
> 5) repeat (1) through (4) 5000 times or T0 timeout (which ever is
> shortest period)
>
> ToneType|Freq-1|Freq-2|Freq-3|Freq-
> 4|FreqMode|ModePrtg|DbLevel|OnDur|Off
> Dur|Rep-Count
> ======================================================================
> ==
> =============
> 17 400 0 0 0 2 0 -100 400
> 350 0
> 17 400 0 0 0 2 0 -40 225
> 525 0
>
>
> pktcSigDevToneTable:
> ToneType|ToneRep-Count|Steady
> =================================
> 17 5000 false(0)
>
>
> Please feel free to provide any comments.
>
> Regards
> Sumanth
>
> -----Original Message-----
> From: Sumanth Channabasappa
> Sent: Tuesday, August 09, 2005 2:37 PM
> To: '[email protected]'
> Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;
> conference call
>
> Folks,
>
> There has been a suggestion (from Phillip Freyman, Motorola) to move
> the 'dBm level', currently under 'PktcSigDevToneTable' to
> 'pktcSigDevMultiFreqToneTable'. This is due to certain examples that
> require this structure.
>
>
>
> _______________________________________________
> IPCDN mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipcdn
------------------------------
_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn
End of IPCDN Digest, Vol 15, Issue 16
*************************************
_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn