Hello Somphol/Justin,
I have resolved the issue by adding the command no supplementary-service
sip moved-temporarily.
Thanks a lot Somphol for pointing the document to me.
Thank you Justin for providing me the inputs.
Regards,
Viki
On Thu, Jan 30, 2014 at 6:15 AM, Justin Carney
Something doesn’t seem to add up in my head. Supp Services shouldn’t effect
DTMF. Did you change anything related to the SIP Trunk on CUCM? Or anything
DTMF related on a dial-peer?
On Jan 30, 2014, at 6:22 AM, Vignesh Sethuraman sethuvign...@gmail.com wrote:
Hello Somphol/Justin,
I have
I understand how DTMF works on SIP Trunks, what I’m not clear on is how “no
supp services” would have an impact on his DTMF issue. I’m trying to understand
the logic of something changing with RFC2833 or SIP NOTIFY to the point where #
is now recognized, yet without changing anything related to
Hope someone can help with this issue I'm having. I am using ucm 8.6 with mgcp
gateways with a pri on the gw. Any user at the site can place a LD call and it
work fine...second user tries to make an LD call and they get reorder tone when
there are available channels. Could anyone give some
Check if the route list get exhausted and need a rest
Do you have traces for the failing call ?
Moataz
-Original Message-
From: Mike O'Nan mdona...@gmail.com
Sender: ccie_voice-boun...@onlinestudylist.com
Date: Thu, 30 Jan 2014 08:29:46
To: ccie_voice@onlinestudylist.com
Subject: [OSL
no supplementary service affect only call forwarding and call transfer , i do
not know how it solve DTMF
Regards,
Moataz Tolba
On Thursday, 30 January 2014, 15:17, Mark Holloway m...@markholloway.com
wrote:
I understand how DTMF works on SIP Trunks, what I’m not clear on is how “no
supp
Here are the debugs from the MGCP GW:
RTR-02#debug isdn q931
RTR-02#debug ccm-manager backhaul packets
Call Manager backhaul packets debugging is on
RTR-02#
Jan 30 08:19:12.546:
cmbh_rcv_callback: -- Receiving backhaul msg for Se0/3/1:23 :
| bk_msg_type = DATA_REQ
|
I just noticed in the trace Outside Dial Tone = NO. I have also confirmed
the LD pattern is not set for off net.
Interesting that when I set to off net it does not give secondary dial tone
until the 3rd digit is dialed. I just watched a video yesterday on how to
change that but can't remember
Pattern is set off net and I fixed the secondary dial tone...still get
reorder tone on 2nd LD call. Any ideas from the debugs I provided?
On Jan 30, 2014 9:45 AM, Mike O'Nan mdona...@gmail.com wrote:
I just noticed in the trace Outside Dial Tone = NO. I have also confirmed
the LD pattern is
I can see the release is coming from the PSTN due to invalid information
elements
Regards,
Moataz Tolba
On Thursday, 30 January 2014, 18:08, Mike O'Nan mdona...@gmail.com wrote:
Pattern is set off net and I fixed the secondary dial tone...still get reorder
tone on 2nd LD call. Any ideas
Its a full PRI from a carrier.
I noticed that as well I was just hoping it was some config error on my end.
This carrier is a pain to work with! Thanks for the input!
div Original message /divdivFrom: Moataz
moataz_m...@yahoo.com /divdivDate:01/30/2014 10:15 AM (GMT-06:00)
As a test you can modify the mgcp setting in cucm to NOT send the outbound
IE. This will confirm whether the Telco is rejecting the call due to
invalid IE.
I recently worked a similar issue where I saw an invalid IE error message
(a rouge prefix on a rp caused the ani to be too long) but the
Hello All,
I have attached the debug ccsip messages output before and after using the
command. I do not have the answer why it resolved the dtmf-issue. If you
guys find something, please share it.
Thanks,
Viki
On Thu, Jan 30, 2014 at 4:16 PM, Moataz moataz_m...@yahoo.com wrote:
no
In the larger debug attachment the SDP includes a=fmtp:18 in the 200 OK coming
from the CME site (IP 3.3.3.3). In the other capture I didn’t see any SDP. If
no DTMF offer is present during call setup, this would assume plain old in-band
DTMF, which won’t work on a compressed codec like G.729.
14 matches
Mail list logo
