AA wont answer SIP Trunk anymore
Ashley
Yesterday at 09:09 AM
Before we switched over to a SIP Trunk, the analogue call would be answered by the Auto Attendant, but since moving over to a SIP Trunk it appears to just ring straight to Group 500.
I've set Trunk Ringing (3.2.1) all to Group 517 which is set at AA.
I've set DID Ringing (3.2.3) to 517 (this doesn't appear to change anything regardless what i enter)
Am i missing something??
Also the Music on Hold which we use to use a prompt from the AA system doesn't play anymore, use to be able to press Hold on a phone and it would play through the speaker??
So confused!!??
0
29
Read More
|
|
Cancel forwarding on ISDN 8510T
Keyset6
04/18/24 06:38 PM
I realize this is 40+ year old technology. I have a question into my telco contact that's familiar with the AT&T 5ESS, which is somewhat different than ours. My customer's remote office has a few AT&T ISDN 8510T phones served from the local CO. The customer wants to forward their main number at times to another phone. The main number is not the primary line on an ISDN phone but is a SLO (Single Line Only) appearance on 2 phones. So, the typical procedure of 72#, (destination), wait for confirmation tone, press the CFV key does not apply.
She successfully forwarded the number by 174+(XXXX, the 4 digit extension). But, the code to cancel forwarding is unknown. In our system, an SLO is forwarded by 78#+ the 5 digit extension, 79# to cancel. The remote office gets a fast busy immediately when pressing 7, and 179+ 5 digits did not work. The CO serving the remote customer is a public CO, and I don't know if it's the same vintage as ours. My contact hasn't been able to research the SLO call forward cancel procedure yet, so I thought I'd give it a shot here.
0
31
Read More
|
|
Things I didn't know about GRANDSTREAM!!
Carl Navarro
04/06/24 01:16 AM
I picked up some Grandstream material in the last week and my surprise began when I couldn't register the secondary stuff to my Cloud account. It appears that they addressed this issue last year. https://www.grandstream.com/online-marketplace-warranty-limitations-policy-pageOops. I suppose it's fair, but GS doesn't want any of the product that you can administer in the cloud to be purchased or resold on the secondary market. Meanwhile, I have a couple of gray systems and 10 or so phones of questionable heritage. :-( Time to figure out a workaround... Carl EDIT: After wailing and gnashing of teeth and texting Grandstream, I am now able to log into my cloud account and add this unit to my systems. The seller (Phillips Communications) on Ebay contacted who he bought it from and they released my new system back into the pool. Now it's mine. It's the first time they have had to deal with the 6300 series systems.
0
651
Read More
|
|
IPO R11.1.3.1.0 DTMF Issue with J1xx phones
Toner
04/05/24 04:51 PM
Hi all, FYI and for our own reference we've found what appears to be a very specific DTMF bug with R11.1.3 and J1xx phones (it doesn't affect 9608 phones). Here's the rundown: A call that is placed which has an immediate shortcode match results in the IPO telling the J1xx phones to use RFC2833 for DTMF. In this example the phone uses it's redial button to place a call:
2024-04-04T17:41:01 56533469mS CMExtnEvt: v=0 State, new=Dialling old=Idle,0,0,80102 AtcomJ1xx
2024-04-04T17:41:01 56533469mS CMTARGET: 0a0597eb30024522 866.805455138.0 17731 80102 AtcomJ1xx.0: LOOKUP CALL ROUTE: GID=0 type=100 called_party=9055551234 sub= calling=8010229 calling_sub= dir=out complete=1 ses=0
2024-04-04T17:41:01 56533469mS CMTARGET: 0a0597eb30024522 866.805455138.0 17731 80102 AtcomJ1xx.0: ADD TARGET (N): number=9058299444 type=100 depth=1 nobar=1 setorig=1 ses=0
2024-04-04T17:41:01 56533470mS CMTARGET: 0a0597eb30024522 866.805455138.0 17731 80102 AtcomJ1xx.0: DEF SC: 9055551234 0 sc=type=Dial code=?, num=.s15875551234
2024-04-04T17:41:01 56533470mS CMTARGET: 0a0597eb30024522 866.805455138.0 17731 80102 AtcomJ1xx.0: INITIAL TARGETING SUCCEEDED
2024-04-04T17:41:01 56533470mS CMTARGET: 0a0597eb30024522 866.805455138.0 17731 80102 AtcomJ1xx.0: GetNoAnswerTimer:20
2024-04-04T17:41:01 56533470mS CMExtnEvt: v=0 State, new=Proceeding old=Dialling,0,0,80102 AtcomJ1xx
First, the IPO placed the call over the SIP trunk. It then sends an INVITE to the J1xx phone (I know, this seems backwards but it's how CCMS signaling seems to work)
2024-04-04T17:41:01 56533757mS SIP Tx: TLS 10.0.0.1:5061 -> 10.0.0.2:5429
INVITE sip:[email protected]:5429;transport=tls SIP/2.0
v: SIP/2.0/TLS 10.0.0.1:5061;rport;branch=z9hG4bKe81d753a9840e4a9997cda7d166df659
f: <sip:[email protected]>;tag=5a4531af994bfd80
t: <sip:[email protected]>;tag=660e61bc532561211k6s6l6u1g3kd4n1n415573_F8010229
i: 1_660e61bc-4833d3c75u26o3h2h56q331zi4w1u_I8010229
CSeq: 574 INVITE
m: <sip:[email protected]:5061;transport=tls>
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INFO,REFER,NOTIFY,SUBSCRIBE,REGISTER,PUBLISH,UPDATE
User-Agent: IP Office 11.1.3.1.0 build 34
c: application/sdp
l: 203
v=0
o=UserA 1563834215 396372004 IN IP4 10.0.0.1
s=Session SDP
c=IN IP4 10.0.0.1
t=0 0
m=audio 50700 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Now a call to a 10 digit number where there is no specific shortcode match and we have to wait for the 4 second timeout:
2024-04-04T17:40:40 56511104mS CMExtnEvt: v=(null) State, new=Idle old=Idle,0,0,8010229: Digit Key Pressed 4
2024-04-04T17:40:40 56511105mS CMTARGET: 0a0597eb30024509 866.805455113.0 17724 80102 AtcomJ1xx.0: Setting Hard Timer 4000
2024-04-04T17:40:40 56511105mS CMTARGET: 0a0597eb30024509 866.805455113.0 17724 80102 AtcomJ1xx.0: LOOKUP CALL ROUTE: GID=0 type=100 called_party=9055551234 sub= calling=8010229 calling_sub= dir=out complete=0 ses=0
2024-04-04T17:40:40 56511105mS CMTARGET: 0a0597eb30024509 866.805455113.0 17724 80102 AtcomJ1xx.0: ADD TARGET (N): number=90555512344 type=100 depth=1 nobar=1 setorig=1 ses=0
(4 seconds later)
2024-04-04T17:40:43 56515105mS CMTARGET: 0a0597eb30024509 866.805455113.0 17724 80102 AtcomJ1xx.0: TimerExpired cause=CMTCDelayedProcessing
2024-04-04T17:40:43 56515105mS CMTARGET: 0a0597eb30024509 866.805455113.0 17724 80102 AtcomJ1xx.0: LOOKUP CALL ROUTE: GID=0 type=100 called_party=9055551234 sub= calling=8010229 calling_sub= dir=out complete=1 ses=0
2024-04-04T17:40:43 56515105mS CMTARGET: 0a0597eb30024509 866.805455113.0 17724 80102 AtcomJ1xx.0: ADD TARGET (N): number=9055551234 type=100 depth=1 nobar=1 setorig=1 ses=0
2024-04-04T17:40:43 56515105mS CMTARGET: 0a0597eb30024509 866.805455113.0 17724 80102 AtcomJ1xx.0: DEF SC: 9055551234 0 sc=type=Dial code=?, num=.s15875551234
2024-04-04T17:40:43 56515106mS CMTARGET: 0a0597eb30024509 866.805455113.0 17724 80102 AtcomJ1xx.0: INITIAL TARGETING SUCCEEDED
2024-04-04T17:40:43 56515106mS CMTARGET: 0a0597eb30024509 866.805455113.0 17724 80102 AtcomJ1xx.0: GetNoAnswerTimer:20
2024-04-04T17:40:43 56515106mS CMExtnEvt: v=0 State, new=Proceeding old=Dialling,0,0,80102 AtcomJ1xx
This time the IPO starts with an INVITE to the J1xx phone but is missing the rFC2833 line and therefore we would expect Inband DTMF.
2024-04-04T17:40:43 56515106mS SIP Tx: TLS 10.0.0.1:5061 -> 10.0.0.2:5429
INVITE sip:[email protected]:5429;transport=tls SIP/2.0
v: SIP/2.0/TLS 10.0.0.1:5061;rport;branch=z9hG4bK4f167ffffdfbb2dd55f6bc0679c87cea
f: <sip:[email protected]>;tag=5a4531af994bfd80
t: <sip:[email protected]>;tag=660e61bc532561211k6s6l6u1g3kd4n1n415573_F8010229
i: 1_660e61bc-4833d3c75u26o3h2h56q331zi4w1u_I8010229
CSeq: 562 INVITE
m: <sip:[email protected]:5061;transport=tls>
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INFO,REFER,NOTIFY,SUBSCRIBE,REGISTER,PUBLISH,UPDATE
User-Agent: IP Office 11.1.3.1.0 build 34
c: application/sdp
l: 121
v=0
o=UserA 1563834215 396372001 IN IP4 10.0.0.1
s=Session SDP
c=IN IP4 10.0.0.1
t=0 0
m=audio 0 RTP/AVP 0
The IPO then places the call over the SIP trunk and specifies RFC2833. Shortly afterward, the J1xx responds with a 200 OK that does not contain the RFC2833 line. A capture of the RTP packets from the J1xx to the IPO proves the DTMF is missing in both methods - RFC2833 and Inband.
0
111
Read More
|
|
Programming OfficeServ 7xxx to forward incoming calls
highlysecptial
03/31/24 02:37 PM
Sorry if this is a very naive question, but can anyone explain to me how to program the OfficeServ Device Manager (I have an OfficeServ 7100) to forward all incoming calls on specific incoming trunks to another external number? Ideally, I would also like to specify which trunk is used for the diverted calls.
Any help would be gratefully received.
0
87
Read More
|
|
|
Forums84
Topics94,290
Posts638,801
Members49,767
| |
Most Online5,661
May 23rd, 2018
|
|
|
1 members (R4+Z),
66
guests, and
429
robots. |
|
Key:
Admin,
Global Mod,
Mod
|
|
|
|
