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: Play IVR after AMD greeting (Abhiram Kramadhati (akramadh))
2. Re: Issue with anonymous calls on a SIP trunk (Andy)
3. Re: Issue with anonymous calls on a SIP trunk
(Brian Meade (brmeade))
4. Streaming audio options (Justin Steinberg)
5. Re: Issue with anonymous calls on a SIP trunk (Andy Carse)
6. Re: Issue with anonymous calls on a SIP trunk
(Brian Meade (brmeade))
7. Re: Issue with anonymous calls on a SIP trunk (Amit Kumar)
8. Re: adding a disclaimer/MOTD in CUCM? (Brian Meade (brmeade))
9. Re: Unicast MOH and MRG Round Robin (Anthony Holloway)
10. Re: Unicast MOH and MRG Round Robin (Brian Meade (brmeade))
11. Unity Connection DRS Restore Failure (Salisbury, Charles)
----------------------------------------------------------------------
Message: 1
Date: Tue, 10 Dec 2013 17:06:02 +0000
From: "Abhiram Kramadhati (akramadh)" <[email protected]>
To: "Abhiram Kramadhati (akramadh)" <[email protected]>, shary shary
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [cisco-voip] Play IVR after AMD greeting
Message-ID: <cecd4681.14933%[email protected]>
Content-Type: text/plain; charset="us-ascii"
The issue of the AsmT being sent by the dialer earlier seems unlikely.
I would suspect that the answering machine is being treated as Human Voice/Low
Volume and therefore the prompt is played. We can confirm that from the logs,
but we should look at that if the issue persists after making the changes on
the SIP configuration page on UCCX specific to AMD. We can then look to see the
SIP UPDATE messages received and review the SIP dialer config if needed.
Regards,
Abhiram Kramadhati
CCIE Voice # 40065
Contact Center TAC
Cisco Systems
From: akramadh <[email protected]<mailto:[email protected]>>
Date: Tuesday, 10 December 2013 10:11 PM
To: shary shary <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: Re: [cisco-voip] Play IVR after AMD greeting
Hi Shary,
When you are working with the UCCX Outbound IVR and Answering machine, the
following is the mechanism:
--The UCCX waits for the CPA update from the Dialer. Based on the repsonse:
Live Speech, Low Volume or Answering Machine, the UCCX will proceed. It is
important to note that an update HAS to come.
-- If it is Answeting Machine, then there has to be a total of 3 UPDATE
messages:
1) The first UPDATE: telling that the CPA has started (Cpas)
UPDATE
sip:[email protected]<mailto:[email protected]>:5065;transport=udp
SIP/2.0
...
Call-ID: [email protected]<mailto:[email protected]>
...
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
Content-Length: 26
event=detected
status=CpaS
2. The second UPDATE message: telling that it detected Answering Machine (Asm)
UPDATE
sip:[email protected]<mailto:[email protected]>:5065;transport=udp
SIP/2.0
Via: SIP/2.0/UDP 172.24.255.8:5060;branch=z9hG4bK24A149F
From:
<sip:[email protected]<mailto:[email protected]>>;tag=20E95654-2025
To: <sip:[email protected]<mailto:[email protected]>>;tag=ds3cb988ab
Date: Thu, 13 Dec 2012 04:40:29 GMT
Call-ID: [email protected]<mailto:[email protected]>
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Timestamp: 1355373631
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
CSeq: 102 UPDATE
Contact: <sip:[email protected]<mailto:[email protected]>:5060>
Min-SE: 1800
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
Content-Length: 168
event=detected
status=Asm
3. The third UPDATE message: telling that it detecting the Answering Machine
Terminating Tone (AsmT)
UPDATE
sip:[email protected]<mailto:[email protected]>:5065;transport=udp
SIP/2.0
Via: SIP/2.0/UDP 172.24.255.8:5060;branch=z9hG4bK24F14B5
From:
<sip:[email protected]<mailto:[email protected]>>;tag=20E95654-2025
To: <sip:[email protected]<mailto:[email protected]>>;tag=ds3cb988ab
Date: Thu, 13 Dec 2012 04:40:29 GMT
Call-ID: [email protected]<mailto:[email protected]>
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Timestamp: 1355373638
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
CSeq: 103 UPDATE
Contact: <sip:[email protected]<mailto:[email protected]>:5060>
Min-SE: 1800
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
Content-Length: 172
event=detected
status=AsmT
The UCCX will start performing its action (say, transfer to script and play
prompt) after AsmT. This is important becasue if it is done after Asm, then the
scenario could be:
Answering machine is saying "Mr X. is not available. Leave message after beep"
<Beep>
We get the Asm after the gateway hears "Mr.X..." but the AsmT is sent after the
Gateway hears <Beep>. If the media is played after Mr.X (Asm), the answering
machine will not be recorfing that prompt and there might be complains that the
initial part of the prompt is not recorded.
So, if the IPIVR is playing the prompt; then it would be because the AsmT
message is received by UCCX. We should look at the UCCX logs and packet
captures to check why and when the AsmT message was received.
Also for AMD, the settings of 'Minimum Silence period' and 'Maximum Term Tone
Analysis' should be changed from the default values to 608 and 30000
respectively:
http://docwiki.cisco.com/wiki/Answering_machine/Voice_Mail_is_not_detected,_it_is_marked_as_voice.
Hope it helps!
Cheers,
Abhiram Kramadhati
CCIE Voice # 40065
From: shary shary <[email protected]<mailto:[email protected]>>
Date: Tuesday, 10 December 2013 9:51 PM
To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: [cisco-voip] Play IVR after AMD greeting
Hi all,
we are facing one challenge in uccx solution with our customer that when system
make an outbound call and customer doesn't pick the call then it starts playing
IVR before end of AMD machine recording.
We need to play the IVR only once the AMD machine stop playing its recording,
so that IVR can be recorded completely. Any way to acheive this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20131210/06ddcd69/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 10 Dec 2013 17:19:12 +0000
From: Andy <[email protected]>
To: "Brian Meade (brmeade)" <[email protected]>, Cisco VoIP List
<[email protected]>
Subject: Re: [cisco-voip] Issue with anonymous calls on a SIP trunk
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Brian,
I only have a sniffer trace to hand at the moment
I've changed the ip addressing and the numbers to protect the innocent.
Internet Protocol Version 4, Src: 10.1.1.2 (10.1.1.2), Dst: 10.1.1.1
(10.1.1.1)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 10.1.1.1:5060;branch=z9hG4bKbjrn5f305g111q46j2j1.1
Transport: UDP
Sent-by Address: 10.1.1.1
Sent-by port: 5060
Branch: z9hG4bKbjrn5f305g111q46j2j1.1
From:
"Anonymous"<sip:[email protected]>;tag=140140856-1386321996272-
SIP Display info: "Anonymous"
SIP from address: sip:[email protected]
SIP from address User Part: anonymous
SIP from address Host Part: 10.1.1.1
SIP tag: 140140856-1386321996272-
To: "44InboundDDI
44InBoundDDI"<sip:44InBoundDDI@"Domain">;tag=585CA458-26EF
SIP Display info: "44InboundDDI 44InBoundDDI"
SIP to address: sip:44InBoundDDI@"Domain"
SIP to address User Part: 44InBoundDDI
SIP to address Host Part: "Domain"
SIP tag: 585CA458-26EF
Date: Fri, 06 Dec 2013 09:26:36 GMT
Call-ID: [email protected]
CSeq: 597521657 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:[email protected]:5060>
Contact-URI: sip:[email protected]:5060
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.3.2.T1
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 246
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent
9234 6163 IN IP4 10.1.1.2
Owner Username: CiscoSystemsSIP-GW-UserAgent
Session ID: 9234
Session Version: 6163
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.1.1.2
Session Name (s): SIP Call
Connection Information (c): IN IP4 "CallManager IP Address"
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 26000
RTP/AVP 0 101
Connection Information (c): IN IP4 "CallManager IP Address"
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): ptime:20
Regards
Andy
On 10/12/2013 14:36, Brian Meade (brmeade) wrote:
> Andy,
>
> Can you copy what the Update message looks like so we can see what header the
> CUCM IP address is in? You should be able to use a SIP Profile on the CUBE
> to change this to the CUBE's external IP address.
>
> Brian
>
> -----Original Message-----
> From: cisco-voip [mailto:[email protected]] On Behalf Of Andy
> Sent: Tuesday, December 10, 2013 6:32 AM
> To: Cisco VoIP List
> Subject: [cisco-voip] Issue with anonymous calls on a SIP trunk
>
> Hi,
> I have an issue with anonymous (callerid witheld) calls on a SIP trunk which
> I can't figure out.
>
> Call comes in over sip trunk via a cube to cucm, if the callerid is know then
> the call gets placed to the dialed number ok.
> But if the number is withheld on the inbound call leg their is an additional
> update message which contains the CUCM ip address, but the SIP provider is
> unable to route to this address so one way voice is the result.
>
> Does anyone have any idea how to fix this?
>
> --
> Regards
>
> Andy
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
------------------------------
Message: 3
Date: Tue, 10 Dec 2013 18:34:38 +0000
From: "Brian Meade (brmeade)" <[email protected]>
To: Andy <[email protected]>, Cisco VoIP List
<[email protected]>
Subject: Re: [cisco-voip] Issue with anonymous calls on a SIP trunk
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Was this capture taken from outside the CUBE? It looks like you might not be
using media flow-through on your dial-peers if that media IP address isn't
getting updated.
Brian
-----Original Message-----
From: Andy [mailto:[email protected]]
Sent: Tuesday, December 10, 2013 12:19 PM
To: Brian Meade (brmeade); Cisco VoIP List
Subject: Re: [cisco-voip] Issue with anonymous calls on a SIP trunk
Hi Brian,
I only have a sniffer trace to hand at the moment I've changed the ip
addressing and the numbers to protect the innocent.
Internet Protocol Version 4, Src: 10.1.1.2 (10.1.1.2), Dst: 10.1.1.1
(10.1.1.1)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session
Initiation Protocol
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 10.1.1.1:5060;branch=z9hG4bKbjrn5f305g111q46j2j1.1
Transport: UDP
Sent-by Address: 10.1.1.1
Sent-by port: 5060
Branch: z9hG4bKbjrn5f305g111q46j2j1.1
From:
"Anonymous"<sip:[email protected]>;tag=140140856-1386321996272-
SIP Display info: "Anonymous"
SIP from address: sip:[email protected]
SIP from address User Part: anonymous
SIP from address Host Part: 10.1.1.1
SIP tag: 140140856-1386321996272-
To: "44InboundDDI
44InBoundDDI"<sip:44InBoundDDI@"Domain">;tag=585CA458-26EF
SIP Display info: "44InboundDDI 44InBoundDDI"
SIP to address: sip:44InBoundDDI@"Domain"
SIP to address User Part: 44InBoundDDI
SIP to address Host Part: "Domain"
SIP tag: 585CA458-26EF
Date: Fri, 06 Dec 2013 09:26:36 GMT
Call-ID: [email protected]
CSeq: 597521657 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:[email protected]:5060>
Contact-URI: sip:[email protected]:5060
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.3.2.T1
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 246
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent
9234 6163 IN IP4 10.1.1.2
Owner Username: CiscoSystemsSIP-GW-UserAgent
Session ID: 9234
Session Version: 6163
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.1.1.2
Session Name (s): SIP Call
Connection Information (c): IN IP4 "CallManager IP Address"
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 26000 RTP/AVP 0 101
Connection Information (c): IN IP4 "CallManager IP Address"
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): ptime:20
Regards
Andy
On 10/12/2013 14:36, Brian Meade (brmeade) wrote:
> Andy,
>
> Can you copy what the Update message looks like so we can see what header the
> CUCM IP address is in? You should be able to use a SIP Profile on the CUBE
> to change this to the CUBE's external IP address.
>
> Brian
>
> -----Original Message-----
> From: cisco-voip [mailto:[email protected]] On Behalf
> Of Andy
> Sent: Tuesday, December 10, 2013 6:32 AM
> To: Cisco VoIP List
> Subject: [cisco-voip] Issue with anonymous calls on a SIP trunk
>
> Hi,
> I have an issue with anonymous (callerid witheld) calls on a SIP trunk which
> I can't figure out.
>
> Call comes in over sip trunk via a cube to cucm, if the callerid is know then
> the call gets placed to the dialed number ok.
> But if the number is withheld on the inbound call leg their is an additional
> update message which contains the CUCM ip address, but the SIP provider is
> unable to route to this address so one way voice is the result.
>
> Does anyone have any idea how to fix this?
>
> --
> Regards
>
> Andy
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
------------------------------
Message: 4
Date: Tue, 10 Dec 2013 13:02:10 -0600
From: Justin Steinberg <[email protected]>
To: Cisco VOIP <[email protected]>
Subject: [cisco-voip] Streaming audio options
Message-ID:
<CACCAghbDJUtTKtZr=_qfxzre4my8mtbuu_motuctfigi7ya...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I have a requirement to enable streaming audio for up to 25-30 live audio
sources and the unique part is that some DID numbers coming in on PRIs need
to automatically be answered and connected to a live audio stream.
I've used FXO/CME live audio with CUCM via multicast, but don't think this
scales to 25-30 sources - atleast I'm thinking there is a better way. Even
if it did, I would need something to answer the call and put it on hold.
So, assuming that I can get the multicast RTP on to the network with a
server, I just need the Cisco voice equipment to listen to the stream.
One way I can think to auto answer and put a call on hold would be with
CCX, but that is ugly because I would need alot of CTI port groups so I can
map to different CUCM CTI music on hold audio sources, and would quickly
eat up alot of ports on CCX due to the requirement to allow multiple
callers the ability to listen to the same audio feed.
I noticed in the dial-peer config, there is an option for 'session protocol
multicast' and then the associated 'session target ipv4:239.x.x.x:yyyyy'.
I've configured this and when calls come in the PRI they are auto answered
but I get just dead silence. I've ruled out a multicast issue by
verifying that when an actual phone puts a PRI caller on hold, the PRI
caller can hear the audio. The weird thing is that when I type 'show
voip rtp connection' on the router, the local IP when using the 'session
protocol multicast' is 255.255.255.255. When I look at that same command
output when an IP phone places a caller on hold, the local IP shows the
proper address assigned to the VG. Under both scenarios, the remote IP
properly shows the correct multicast address (e.g. 239.x.x.x). I know
that the 'session protocol multicast' was made for hoot-n-holler, so I'm
thinking it just wasn't designed to do what I am trying. I've tried
several levels of IOS and get the same behavior.
As a plan B, I've created a VXML script and tied it to a POTS dialpeer and
had the VXML script request audio from a RTSP server. This works, but I'd
prefer the multicast option. I've not yet found a RTSP server that seems
to fit my requirements of so many live audio feeds.
If someone can think of another option to get 25-30 live feeds tied to a
DID number I would appreciate that as well.
Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20131210/b9c6b44d/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 10 Dec 2013 19:07:07 +0000
From: Andy Carse <[email protected]>
To: "Brian Meade, (brmeade)" <[email protected]>
Cc: Cisco VoIP List <[email protected]>
Subject: Re: [cisco-voip] Issue with anonymous calls on a SIP trunk
Message-ID:
<CAJS_s=-dScJH=_gcaq_fred+wd0zfsnk5q0y_1_9bhbrgmr...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Yes it was taken at the providers end of sip trunk.
On 10 Dec 2013 18:34, "Brian Meade (brmeade)" <[email protected]> wrote:
> Was this capture taken from outside the CUBE? It looks like you might not
> be using media flow-through on your dial-peers if that media IP address
> isn't getting updated.
>
> Brian
>
> -----Original Message-----
> From: Andy [mailto:[email protected]]
> Sent: Tuesday, December 10, 2013 12:19 PM
> To: Brian Meade (brmeade); Cisco VoIP List
> Subject: Re: [cisco-voip] Issue with anonymous calls on a SIP trunk
>
> Hi Brian,
> I only have a sniffer trace to hand at the moment I've changed the ip
> addressing and the numbers to protect the innocent.
>
> Internet Protocol Version 4, Src: 10.1.1.2 (10.1.1.2), Dst: 10.1.1.1
> (10.1.1.1)
> User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session
> Initiation Protocol
> Status-Line: SIP/2.0 200 OK
> Status-Code: 200
> [Resent Packet: False]
> Message Header
> Via: SIP/2.0/UDP 10.1.1.1:5060
> ;branch=z9hG4bKbjrn5f305g111q46j2j1.1
> Transport: UDP
> Sent-by Address: 10.1.1.1
> Sent-by port: 5060
> Branch: z9hG4bKbjrn5f305g111q46j2j1.1
> From:
> "Anonymous"<sip:[email protected]>;tag=140140856-1386321996272-
> SIP Display info: "Anonymous"
> SIP from address: sip:[email protected]
> SIP from address User Part: anonymous
> SIP from address Host Part: 10.1.1.1
> SIP tag: 140140856-1386321996272-
> To: "44InboundDDI
> 44InBoundDDI"<sip:44InBoundDDI@"Domain">;tag=585CA458-26EF
> SIP Display info: "44InboundDDI 44InBoundDDI"
> SIP to address: sip:44InBoundDDI@"Domain"
> SIP to address User Part: 44InBoundDDI
> SIP to address Host Part: "Domain"
> SIP tag: 585CA458-26EF
> Date: Fri, 06 Dec 2013 09:26:36 GMT
> Call-ID: [email protected]
> CSeq: 597521657 INVITE
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
> SUBSCRIBE, NOTIFY, INFO, REGISTER
> Allow-Events: telephone-event
> Contact: <sip:[email protected]:5060>
> Contact-URI: sip:[email protected]:5060
> Supported: replaces
> Supported: sdp-anat
> Server: Cisco-SIPGateway/IOS-15.3.2.T1
> Supported: timer
> Content-Type: application/sdp
> Content-Disposition: session;handling=required
> Content-Length: 246
> Message Body
> Session Description Protocol
> Session Description Protocol Version (v): 0
> Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent
> 9234 6163 IN IP4 10.1.1.2
> Owner Username: CiscoSystemsSIP-GW-UserAgent
> Session ID: 9234
> Session Version: 6163
> Owner Network Type: IN
> Owner Address Type: IP4
> Owner Address: 10.1.1.2
> Session Name (s): SIP Call
> Connection Information (c): IN IP4 "CallManager IP Address"
> Time Description, active time (t): 0 0
> Session Start Time: 0
> Session Stop Time: 0
> Media Description, name and address (m): audio 26000 RTP/AVP
> 0 101
> Connection Information (c): IN IP4 "CallManager IP Address"
> Media Attribute (a): rtpmap:0 PCMU/8000
> Media Attribute (a): rtpmap:101 telephone-event/8000
> Media Attribute (a): fmtp:101 0-15
> Media Attribute (a): ptime:20
>
> Regards
>
> Andy
>
> On 10/12/2013 14:36, Brian Meade (brmeade) wrote:
> > Andy,
> >
> > Can you copy what the Update message looks like so we can see what
> header the CUCM IP address is in? You should be able to use a SIP Profile
> on the CUBE to change this to the CUBE's external IP address.
> >
> > Brian
> >
> > -----Original Message-----
> > From: cisco-voip [mailto:[email protected]] On Behalf
> > Of Andy
> > Sent: Tuesday, December 10, 2013 6:32 AM
> > To: Cisco VoIP List
> > Subject: [cisco-voip] Issue with anonymous calls on a SIP trunk
> >
> > Hi,
> > I have an issue with anonymous (callerid witheld) calls on a SIP trunk
> which I can't figure out.
> >
> > Call comes in over sip trunk via a cube to cucm, if the callerid is know
> then the call gets placed to the dialed number ok.
> > But if the number is withheld on the inbound call leg their is an
> additional update message which contains the CUCM ip address, but the SIP
> provider is unable to route to this address so one way voice is the result.
> >
> > Does anyone have any idea how to fix this?
> >
> > --
> > Regards
> >
> > Andy
> >
> > _______________________________________________
> > cisco-voip mailing list
> > [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/20131210/f51c6c75/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 10 Dec 2013 19:46:52 +0000
From: "Brian Meade (brmeade)" <[email protected]>
To: Andy Carse <[email protected]>
Cc: Cisco VoIP List <[email protected]>
Subject: Re: [cisco-voip] Issue with anonymous calls on a SIP trunk
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Can you verify if you have your dial-peers set up for media flow-through?
From: Andy Carse [mailto:[email protected]]
Sent: Tuesday, December 10, 2013 2:07 PM
To: Brian Meade (brmeade)
Cc: Cisco VoIP List
Subject: RE: [cisco-voip] Issue with anonymous calls on a SIP trunk
Yes it was taken at the providers end of sip trunk.
On 10 Dec 2013 18:34, "Brian Meade (brmeade)"
<[email protected]<mailto:[email protected]>> wrote:
Was this capture taken from outside the CUBE? It looks like you might not be
using media flow-through on your dial-peers if that media IP address isn't
getting updated.
Brian
-----Original Message-----
From: Andy [mailto:[email protected]<mailto:[email protected]>]
Sent: Tuesday, December 10, 2013 12:19 PM
To: Brian Meade (brmeade); Cisco VoIP List
Subject: Re: [cisco-voip] Issue with anonymous calls on a SIP trunk
Hi Brian,
I only have a sniffer trace to hand at the moment I've changed the ip
addressing and the numbers to protect the innocent.
Internet Protocol Version 4, Src: 10.1.1.2 (10.1.1.2), Dst: 10.1.1.1
(10.1.1.1)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session
Initiation Protocol
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 10.1.1.1:5060;branch=z9hG4bKbjrn5f305g111q46j2j1.1
Transport: UDP
Sent-by Address: 10.1.1.1
Sent-by port: 5060
Branch: z9hG4bKbjrn5f305g111q46j2j1.1
From:
"Anonymous"<sip:[email protected]<mailto:sip%[email protected]>>;tag=140140856-1386321996272-
SIP Display info: "Anonymous"
SIP from address:
sip:[email protected]<mailto:sip%[email protected]>
SIP from address User Part: anonymous
SIP from address Host Part: 10.1.1.1
SIP tag: 140140856-1386321996272-
To: "44InboundDDI
44InBoundDDI"<sip:44InBoundDDI@"Domain"<sip:44InBoundDDI@%22Domain%22>>;tag=585CA458-26EF
SIP Display info: "44InboundDDI 44InBoundDDI"
SIP to address:
sip:44InBoundDDI@"Domain<sip:44InBoundDDI@%22Domain>"
SIP to address User Part: 44InBoundDDI
SIP to address Host Part: "Domain"
SIP tag: 585CA458-26EF
Date: Fri, 06 Dec 2013 09:26:36 GMT
Call-ID:
[email protected]<mailto:[email protected]>
CSeq: 597521657 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact:
<sip:[email protected]:5060<http://sip:[email protected]:5060>>
Contact-URI:
sip:[email protected]:5060<http://sip:[email protected]:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.3.2.T1
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 246
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent
9234 6163 IN IP4 10.1.1.2
Owner Username: CiscoSystemsSIP-GW-UserAgent
Session ID: 9234
Session Version: 6163
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.1.1.2
Session Name (s): SIP Call
Connection Information (c): IN IP4 "CallManager IP Address"
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 26000 RTP/AVP 0 101
Connection Information (c): IN IP4 "CallManager IP Address"
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): ptime:20
Regards
Andy
On 10/12/2013 14:36, Brian Meade (brmeade) wrote:
> Andy,
>
> Can you copy what the Update message looks like so we can see what header the
> CUCM IP address is in? You should be able to use a SIP Profile on the CUBE
> to change this to the CUBE's external IP address.
>
> Brian
>
> -----Original Message-----
> From: cisco-voip
> [mailto:[email protected]<mailto:[email protected]>]
> On Behalf
> Of Andy
> Sent: Tuesday, December 10, 2013 6:32 AM
> To: Cisco VoIP List
> Subject: [cisco-voip] Issue with anonymous calls on a SIP trunk
>
> Hi,
> I have an issue with anonymous (callerid witheld) calls on a SIP trunk which
> I can't figure out.
>
> Call comes in over sip trunk via a cube to cucm, if the callerid is know then
> the call gets placed to the dialed number ok.
> But if the number is withheld on the inbound call leg their is an additional
> update message which contains the CUCM ip address, but the SIP provider is
> unable to route to this address so one way voice is the result.
>
> Does anyone have any idea how to fix this?
>
> --
> Regards
>
> Andy
>
> _______________________________________________
> 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/20131210/b2f5b6d4/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 10 Dec 2013 19:55:24 +0530
From: Amit Kumar <[email protected]>
To: Andy <[email protected]>
Cc: Cisco VoIP List <[email protected]>
Subject: Re: [cisco-voip] Issue with anonymous calls on a SIP trunk
Message-ID:
<CAHAsEL4tmDJmuWSk98ua2H-2Wq=ugudowrzc3s2fb+nuzcq...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
debug ccsip message , along with debug ccsip info, would be good to start
with.
On Tue, Dec 10, 2013 at 5:01 PM, Andy <[email protected]> wrote:
> Hi,
> I have an issue with anonymous (callerid witheld) calls on a SIP trunk
> which I can't figure out.
>
> Call comes in over sip trunk via a cube to cucm, if the callerid is know
> then the call gets placed to the dialed number ok.
> But if the number is withheld on the inbound call leg their is an
> additional update message which contains the CUCM ip address, but the SIP
> provider is unable to route to this address so one way voice is the result.
>
> Does anyone have any idea how to fix this?
>
> --
> Regards
>
> Andy
>
> _______________________________________________
> cisco-voip mailing list
> [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/20131210/cc69c16a/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 10 Dec 2013 21:47:30 +0000
From: "Brian Meade (brmeade)" <[email protected]>
To: Anthony Holloway <[email protected]>, Erick Wellnitz
<[email protected]>
Cc: cisco-voip <[email protected]>
Subject: Re: [cisco-voip] adding a disclaimer/MOTD in CUCM?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
So just wanted to close the loop on this issue. We ended up finding CSCuh52758
had already been opened for this issue and evaluated by PSIRT (our security
team). Currently this is only fixed in 10.0 but should get hopefully pushed
into older releases in upcoming Engineering Specials/SUs. If you want this fix
in your version, make sure to open a TAC case so we can get an ES built for
your version with this fix.
Also in case anyone else finds any potential security vulnerabilities, feel
free to reach out to our PSIRT team
(http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html).
Thanks,
Brian
From: cisco-voip [mailto:[email protected]] On Behalf Of Brian
Meade (brmeade)
Sent: Saturday, November 30, 2013 10:43 AM
To: Anthony Holloway; Erick Wellnitz
Cc: cisco-voip
Subject: Re: [cisco-voip] adding a disclaimer/MOTD in CUCM?
Interesting finds. I?m going to see if I can still reproduce this on the
latest versions and possibly get a bug opened for this. I wonder how many
people legitimately use the HTML feature though.
Brian
From: cisco-voip [mailto:[email protected]] On Behalf Of
Anthony Holloway
Sent: Wednesday, November 27, 2013 3:08 PM
To: Erick Wellnitz
Cc: cisco-voip
Subject: Re: [cisco-voip] adding a disclaimer/MOTD in CUCM?
FWIW, you can use this MOTD feature to inject HTML, CSS, VBScript and
Javascript into the login/about pages of CUCM.
With that knowledge, you could do things such as:
1. Embed a partner logo on client systems with pertinent support contact
information
2. Embed a random tip of the day for your administrators (use JS to ID the
location as ccmadmin)
3. Embed a random tip of the day for your users (use JS to ID the location
as ccmuser)
4. Embed links to training material/intranet sites for your users (ccmuser)
5. Embed a link to open a phone ticket for your users (ccmuser)
6. Pre-fill the login form and auto submit for auto-login (maybe a lab usage
thing only)
7. Place a red text warning about some critical service down on April Fools
day for your manager/co-workers to sweat over
8. Change the onSubmit event listener to HTTP GET/POST the j_username and
j_password field values to a third party server, effectively stealing peoples
passwords as they login to CUCM
That last one is not advised. I only mentioned it to illustrate the evil side
of being allowed to inject code into code. Perhaps Cisco should fix this by
escaping the MOTD HTML tags? And while we're on the topic of stealing people's
passwords from CUCM, we're securing our LDAP integrations right?
admin:utils network capture numeric count 100000 size ALL file ldap
admin:file get activelog platform/cli/ldap.cap
wireshark filter: ldap.bindRequest
Ok ok, so some of you are like: "why would I want to do any of that?" And
you're right, these are not the best ideas I've ever had; however, knowing that
the possibilities even exist has its benefit.
I've actually done each one of these as an exercise, so if you want to know
more or need help getting a working solution put together, let me know.
Also, it should be obvious too then, that the CLI representation of the MOTD
cannot do these things, but it will still spit out the ugly HTML/code you are
trying to inject. I have gotten around that a little bit by doing two things:
1. Make the injection as small as possible, leveraging off box resources
(JS, images, etc.)
2. Put a bunch of newlines at the end of the file, which causes the terminal
window to scroll the MOTD out of the view port and possibly out of the buffer.
I hope you found that useful.
On Tue, Nov 26, 2013 at 1:17 PM, Erick Wellnitz
<[email protected]<mailto:[email protected]>> wrote:
Okay...I'm either behind the times or our partner has some explaining to do.
At install, our partner added a 'disclaimer' to both the CLI and web admin
pages of CUCM 9.x
Last I knew, you had to 'hack' root access to do this. Is that still the case
or is there somewhere to set and change this?
Thanks!
_______________________________________________
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/20131210/11585e95/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 10 Dec 2013 23:38:10 -0600
From: Anthony Holloway <[email protected]>
To: Cisco VoIP Group <[email protected]>
Subject: Re: [cisco-voip] Unicast MOH and MRG Round Robin
Message-ID:
<cacrcjojskcekq+rhfork6f9pnm_yk9mtqtkhbltaylxen6f...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Here is the defect for this issue, and the fix is in 10.5
https://tools.cisco.com/bugsearch/bug/CSCul53246
On Mon, Nov 4, 2013 at 3:13 PM, Anthony Holloway <
[email protected]> wrote:
> It was case sensitivity on the MOH server name.
>
> If you rename your MOH from MOH_2 to Sub2_MOH you will see it happen as
> well.
>
> I played with all capitals and it started working.
>
> I will report this via TAC and get an update out to the list.
>
> Thanks Daniel.
>
>
> On Monday, November 4, 2013, Anthony Holloway wrote:
>
>> That was helpful, thank you.
>>
>> It looks like the issue is the counter not being incremented.
>>
>> RTMT is showing 150 active streams and the SDI trace shows a counter of 0
>> for all four MOH.
>>
>> In the SDI trace I see the line:
>> 14:44:32.746 |MRM::updateMohCounter devName=SUB02B_MOH, countChange=1...
>>
>> My actual MOH server is named Sub02b_MOH. note the case difference. I'm
>> wonder if you have a case discrepancy as well?
>>
>> I too am running 8.6(2a). Specifically 8.6.2.22029-1.
>>
>> Thanks again.
>>
>> On Monday, November 4, 2013, Daniel Pagan wrote:
>>
>> This is also my understanding of how CUCM allocates the same media
>> resource type within the same MRG. My lab is currently on 8.6(2)a and I?m
>> unable to recreate the problem ? I?ve placed two calls, back to back, and
>> put both on hold while having two MOH servers (MOH_2 and MOH_3) in the same
>> MRG assigned to the called device MRGL. CUCM allocated MOH_3 for the first
>> call and MOH_2 for the second call.
>>
>>
>>
>> Going to CCM SDI traces, do you see CUCM immediately allocating the same
>> MOH server? In other words, is there a chance you might have missed
>> previous MOH allocation failures for your other MOH resources in the trace
>> file? Do you see a *sendMohAllocateRequestToDevice* event for other MOH
>> resources prior to the allocation of the overused MOH server?
>>
>>
>>
>> Also, some trace entries that might be of interest:
>>
>>
>>
>> MediaResourceCdpc(8)::createLookupTbl Name=MOH_2
>> Cepn=cfb5e1cd-fa16-495f-a380-7b7e75b1887c Weight=0 Group=0 Counter=0
>>
>> MediaResourceCdpc(8)::createLookupTbl Name=MOH_3
>> Cepn=cf2d51e6-ece4-403b-b096-ed188521ab40 Weight=0 Group=0 Counter=1
>>
>>
>>
>> *(counter = number of simultaneous allocations)*
>>
>> *(group = the MRG priority within the MRGL)*
>>
>>
>>
>> In the slight chance you do see other (failed) MOH allocation requests
>> prior to the allocation of your overused MOH server, I would also look at
>> and compare the capabilities for the MOH and held party to make sure
>> there?s a match:
>>
>>
>>
>> logCapabilitiesinTrace -- MOH Caps = 4
>>
>> logCapabilitiesinTrace -- Held Party Caps = 4 2 10
>>
>>
>>
>> *(4 = g711ulaw? 2= alaw)*
>>
>>
>>
>> Hopefully some of this helps.
>>
>>
>>
>> Thx
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20131210/81b5379b/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 11 Dec 2013 14:49:53 +0000
From: "Brian Meade (brmeade)" <[email protected]>
To: Anthony Holloway <[email protected]>, Cisco VoIP
Group <[email protected]>
Subject: Re: [cisco-voip] Unicast MOH and MRG Round Robin
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
If anyone needs this fix on 8.x or 9.x, open a TAC case and we can get this put
into an ES for you.
Brian
From: cisco-voip [mailto:[email protected]] On Behalf Of
Anthony Holloway
Sent: Wednesday, December 11, 2013 12:38 AM
To: Cisco VoIP Group
Subject: Re: [cisco-voip] Unicast MOH and MRG Round Robin
Here is the defect for this issue, and the fix is in 10.5
https://tools.cisco.com/bugsearch/bug/CSCul53246
On Mon, Nov 4, 2013 at 3:13 PM, Anthony Holloway
<[email protected]<mailto:[email protected]>> wrote:
It was case sensitivity on the MOH server name.
If you rename your MOH from MOH_2 to Sub2_MOH you will see it happen as well.
I played with all capitals and it started working.
I will report this via TAC and get an update out to the list.
Thanks Daniel.
On Monday, November 4, 2013, Anthony Holloway wrote:
That was helpful, thank you.
It looks like the issue is the counter not being incremented.
RTMT is showing 150 active streams and the SDI trace shows a counter of 0 for
all four MOH.
In the SDI trace I see the line:
14:44:32.746 |MRM::updateMohCounter devName=SUB02B_MOH, countChange=1...
My actual MOH server is named Sub02b_MOH. note the case difference. I'm wonder
if you have a case discrepancy as well?
I too am running 8.6(2a). Specifically 8.6.2.22029-1.
Thanks again.
On Monday, November 4, 2013, Daniel Pagan wrote:
This is also my understanding of how CUCM allocates the same media resource
type within the same MRG. My lab is currently on 8.6(2)a and I?m unable to
recreate the problem ? I?ve placed two calls, back to back, and put both on
hold while having two MOH servers (MOH_2 and MOH_3) in the same MRG assigned to
the called device MRGL. CUCM allocated MOH_3 for the first call and MOH_2 for
the second call.
Going to CCM SDI traces, do you see CUCM immediately allocating the same MOH
server? In other words, is there a chance you might have missed previous MOH
allocation failures for your other MOH resources in the trace file? Do you see
a sendMohAllocateRequestToDevice event for other MOH resources prior to the
allocation of the overused MOH server?
Also, some trace entries that might be of interest:
MediaResourceCdpc(8)::createLookupTbl Name=MOH_2
Cepn=cfb5e1cd-fa16-495f-a380-7b7e75b1887c Weight=0 Group=0 Counter=0
MediaResourceCdpc(8)::createLookupTbl Name=MOH_3
Cepn=cf2d51e6-ece4-403b-b096-ed188521ab40 Weight=0 Group=0 Counter=1
(counter = number of simultaneous allocations)
(group = the MRG priority within the MRGL)
In the slight chance you do see other (failed) MOH allocation requests prior to
the allocation of your overused MOH server, I would also look at and compare
the capabilities for the MOH and held party to make sure there?s a match:
logCapabilitiesinTrace -- MOH Caps = 4
logCapabilitiesinTrace -- Held Party Caps = 4 2 10
(4 = g711ulaw? 2= alaw)
Hopefully some of this helps.
Thx
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20131211/d98a4511/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 11 Dec 2013 16:08:28 +0000
From: "Salisbury, Charles" <[email protected]>
To: "cisco-voip ([email protected])
([email protected])" <[email protected]>
Subject: [cisco-voip] Unity Connection DRS Restore Failure
Message-ID:
<9f07c1969322db428f43055d7eb33b1579657...@zvm204-maildb2.gentex.com>
Content-Type: text/plain; charset="us-ascii"
Trying to restore a DRS backup on version 7.1.5ES33.32900-33 . Taken on a MCS
server trying to restore to a VM. Errors out with the following:
oninit: Cannot open chunk '/var/opt/cisco/connection/db/dyn2_dbs'. errno = 2
Physical restore failed - Cannot Open Primary Chunk
'/var/opt/cisco/connection/db/dyn2_dbs'
Not having much luck with troubleshooting this error.
Thanks,
CS
THE INFORMATION CONTAINED IN THIS E-MAIL MESSAGE AND ANY ATTACHMENTS SENT FROM
GENTEX CORPORATION IS GENTEX CONFIDENTIAL INFORMATION INTENDED ONLY FOR THE
PERSONAL USE OF THE INDIVIDUAL OR ENTITY NAMED ABOVE. If you are not the
intended recipient, you are hereby notified that any review, distribution, or
copying of this communication is strictly prohibited. If you have received this
communication in error, please immediately notify the sender by return e-mail,
and delete this e-mail message and any attachments from your computer.
------------------------------
Subject: Digest Footer
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
------------------------------
End of cisco-voip Digest, Vol 122, Issue 7
******************************************
