Send cisco-voip mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-voip
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 cisco-voip digest..."
Today's Topics:
1. Re: H.323 DTMF to SIP 2833 (Divin John (dijohn))
2. Re: prefix digits for outbound calls (Divin John (dijohn))
3. Re: prefix digits for outbound calls (Erick Wellnitz)
4. Is CUPS required to get phone status / user status for
Attendant Console 9.1? (Robert Kulagowski)
----------------------------------------------------------------------
Message: 1
Date: Thu, 18 Jul 2013 08:44:27 +0000
From: "Divin John (dijohn)" <[email protected]>
To: "Chris Ward (chrward)" <[email protected]>, Mark Holloway
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] H.323 DTMF to SIP 2833
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="windows-1252"
SCCP and SIP Phones support OOB and in band.
CUCM does rtp-nte only out a SIP trunk.
H323 Trunks don't support RFc2833 (inband)
H323 to SIP would need a MTP if you need to convert OOB (h323 side) to
rtp-nte/inband (SIP side). CUCM would automatically pick up a MTP for DTMF
inter-networking.
Regards,
Divin
From: "Chris Ward (chrward)" <[email protected]<mailto:[email protected]>>
Date: Wednesday, 17 July 2013 8:48 PM
To: Mark Holloway <[email protected]<mailto:[email protected]>>
Cc: Divin John <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: RE: [cisco-voip] H.323 DTMF to SIP 2833
Since its in-band, it wouldn?t require an MTP? The 2833 would flow as part of
the RTP stream.
Adding rtp-nte to the dial peer should remove the need for an MTP if the other
leg (from CUCM?s perspective at least) is SIP.
+Chris
Unity Connection TME
From: Mark Holloway [mailto:[email protected]]
Sent: Wednesday, July 17, 2013 11:08 AM
To: Chris Ward (chrward)
Cc: Divin John (dijohn);
[email protected]<mailto:[email protected]>
Subject: Re: [cisco-voip] H.323 DTMF to SIP 2833
Wouldn't this still require MTP? It looks like he is trying to avoid using MTP
for the conversion.
On Jul 17, 2013, at 9:17 AM, Chris Ward (chrward)
<[email protected]<mailto:[email protected]>> wrote:
CUCM support RFC2833 so long as one of the legs is SIP. An H323 to SIP call
through CUCM should allow RFC2833.
+Chris
Unity Connection TME
From: cisco-voip
[mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Mark Holloway
Sent: Wednesday, July 17, 2013 8:13 AM
To: Divin John (dijohn)
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [cisco-voip] H.323 DTMF to SIP 2833
John is correct, if you're using Alphanumeric on H323 you should be able to use
SIP INFO without the need of an MTP. The question is what's on the other end of
the SIP Trunk, and will they support SIP INFO?
DTMF interworking between SIP and H.323 in the signaling plane, using the
Alphanumeric method
of UserInputIndication
On Jul 16, 2013, at 1:29 PM, Divin John (dijohn)
<[email protected]<mailto:[email protected]>> wrote:
CUCM on the H323 leg doesn't support rfc2833 (rtp-nte).
So, to stop CUCM from invoking an MTP, the SIP side should support Out of band
(notify maybe)
Regards,
Divin
From: Nate VanMaren <[email protected]<mailto:[email protected]>>
Date: Tuesday, 11 June 2013 1:26 AM
To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: [cisco-voip] H.323 DTMF to SIP 2833
What H.323 DTMF method can I use on a H.323 dial-peer to CUCM that will not
invoke an MTP when the outbound side of CUCM is a SIP Trunk that is configured
to use 2833.
I am currently using h245-alphanumeric, which seems to be invoking an MTP.
Thanks,
-Nate
NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies of
the original message.
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130718/1ad16ac1/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 18 Jul 2013 08:52:32 +0000
From: "Divin John (dijohn)" <[email protected]>
To: Erick Wellnitz <[email protected]>, cisco-voip
<[email protected]>
Subject: Re: [cisco-voip] prefix digits for outbound calls
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Erick,
It's Route-Pattern < Routelist/RouteGroup < Gateway
If you have transformations at RP and Route-list/RG level, RL/RG takes
precedence. CUCM ignores the edits at RP level.
If you have transformations at RP, RL/RG and Gateway level, Gateway trumps
everything else. So, we ignore RP and RL/RG level transformations.
Regards,
Divin
From: Erick Wellnitz <[email protected]<mailto:[email protected]>>
Date: Wednesday, 17 July 2013 8:52 PM
To: cisco-voip <[email protected]<mailto:[email protected]>>
Subject: [cisco-voip] prefix digits for outbound calls
I'm seeing some odd behavior in my route lists for prefixing digits.
If I prefix digits at the route pattern level everything works fine. If I try
to prefix digits at the route list level (on each route group assigned to the
route list) the digits are not prefixed.
My pattern is 9011.44XXXXXXXXXX
I strip predot on the route pattern then I prefix + and the call routes over
our sip trunk as expected.
If I strip predot on the route pattern and prefix + at the RL level the + is
not prefixed and the call fails.
My educated guess is that perhaps I should not strip predot at the pattern
level nad instead do it at the RL level.
I am unable to do much testing until close of business.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130718/f2257c6e/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 18 Jul 2013 09:07:00 -0500
From: Erick Wellnitz <[email protected]>
To: "Divin John (dijohn)" <[email protected]>
Cc: cisco-voip <[email protected]>
Subject: Re: [cisco-voip] prefix digits for outbound calls
Message-ID:
<cak0woscapg1nv+a_rt+fups5qbztztph5meecgtjzc1ekcb...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Excellent explanation. I knew I was missing some sort of logic in the
processing.
On Thu, Jul 18, 2013 at 3:52 AM, Divin John (dijohn) <[email protected]>wrote:
> Erick,
>
> It's Route-Pattern < Routelist/RouteGroup < Gateway
>
> If you have transformations at RP and Route-list/RG level, RL/RG takes
> precedence. CUCM ignores the edits at RP level.
> If you have transformations at RP, RL/RG and Gateway level, Gateway trumps
> everything else. So, we ignore RP and RL/RG level transformations.
>
>
> Regards,
> Divin
>
>
> From: Erick Wellnitz <[email protected]>
> Date: Wednesday, 17 July 2013 8:52 PM
> To: cisco-voip <[email protected]>
> Subject: [cisco-voip] prefix digits for outbound calls
>
> I'm seeing some odd behavior in my route lists for prefixing digits.
>
> If I prefix digits at the route pattern level everything works fine. If I
> try to prefix digits at the route list level (on each route group assigned
> to the route list) the digits are not prefixed.
>
> My pattern is 9011.44XXXXXXXXXX
> I strip predot on the route pattern then I prefix + and the call routes
> over our sip trunk as expected.
>
> If I strip predot on the route pattern and prefix + at the RL level the +
> is not prefixed and the call fails.
>
> My educated guess is that perhaps I should not strip predot at the pattern
> level nad instead do it at the RL level.
>
> I am unable to do much testing until close of business.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130718/f4a5c9cd/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 18 Jul 2013 10:51:52 -0500
From: Robert Kulagowski <[email protected]>
To: Cisco VOIP <[email protected]>
Subject: [cisco-voip] Is CUPS required to get phone status / user
status for Attendant Console 9.1?
Message-ID:
<cage0w3s3j7+jq_y58qkngmw_jlevzhcn12bafepqcm522hl...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I watched the video over at the Arcsoft website
(http://www.arcsolutions.com/North_America/Solutions/Products/video/CUEAC_Overview.aspx)
and must have been too distracted by the presenter and may have missed
it.
Hint: do not do a presentation / recording when you have a cold.
Sniffling into the microphone every 5 seconds is pretty annoying.
If I deploy CUEAC 9.1 Enterprise (to replace our old attendant console
software which we've dragged forward all the way from 4.1) what do I
need to give me:
1- phone presence.
2- user status.
Is CUPS required for CUEAC to know whether I'm at my PC, if we're in a
Microsoft environment and we're running MOC / Lync?
Will CUEAC be able to tell the operator that I've set my calendar in
Outlook to "Out of Office"?
Will CUEAC be able to tell the operator that I'm on the phone, or that
I've set it to "Call Forward All"?
Any other products that people like other than CUEAC?
Thanks.
------------------------------
Subject: Digest Footer
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
------------------------------
End of cisco-voip Digest, Vol 117, Issue 15
*******************************************
