Re: [cisco-voip] Making a message appear anonymous/unknown via single inbox
Justin, For clarification, you have a user(s) that makes an outbound call from call manager to the pstn (via a sip trunk to an itsp?) And some of them want to block their Caller ID or mask it to anon? Thanks, Ryan Original Message From: Justin Steinberg jsteinb...@gmail.com Sent: Tuesday, June 23, 2015 11:06 AM To: Ted Nugent tednugen...@gmail.com Subject: Re: [cisco-voip] Making a message appear anonymous/unknown via single inbox CC: Cisco VoIPoE List cisco-voip@puck.nether.net Apologies for resurrecting an old thread here, but I was curious if there was fixed in more recent versions of Unity Connection. I'm trying this with 10.5(2)su1 with SIP trunk between UCM and UCXN and having the problem where UCXN ignores the restriction settings configured on CUCM. I'm thinking maybe I could make a LUA script on the UCM sip trunk to UCXN, but looking for an easier solution. In my situation, I have certain callers that want to have their CLID blocked. So it is based on the placing the call, not the phone that receives the call and I think this prevents me from using the two options discussed here earlier. Justin On Thu, Jan 24, 2013 at 4:28 PM, Ted Nugent tednugen...@gmail.com wrote: Thanks Chris I like option 2 as well since they only have 24 ports as it stands. I'll give it a shot and let you know how it turns out. Thanks again! On Thu, Jan 24, 2013 at 3:16 PM, Chris Ward (chrward) chrw...@cisco.com wrote: Hi Ted, Seems like you are hitting some known limitations. The settings in CUCM for restricting Calling Party Information don’t really eliminate it, it seems to just mark it as “Restricted” so the information remains and CUC seems hell-bent on finding calling party information. I did find 2 solutions for you, both of which use SIP: 1) Setup an additional integration between CUCM and CUC that is meant only for this anonymous line. In the SIP trunk config, you have to uncheck the “Remote-Party-Id” under the “Call Routing Information” section and make sure “Calling Line ID Presentation” is set to Restricted under the “Outbound Calls” section. This will result in an “Unknown CallerID” message in Outlook. 2) Setup a Loopback SIP trunk for calls to this specific Anonymous DID. You only need one SIP trunk to point to CUCMs own IP address, it acts as the outbound and inbound SIP trunk in this scenario. Under the “Outbound Calls” section, you would need define a Calling Party Transformation CSS that would have access to a transformation pattern that matches all Calling parties (remembering that only calls to this anonymous DID are affected) and mask the calling party with some obscure mask like or you can put a . at the end of the pattern you match and then drop all pre-dot if you want it blank. On the route pattern that points to this loopback SIP trunk, you would modify the called party so that once the call re-enters CUCM, it will be destined for the *7999 number (pulled from you example before) and continues through the normal process to be forwarded to voicemail. Neither solution is super-attractive, but both will work. I personally like #2 since it means you won’t have split up your CUC ports for a separate SIP integration. Let me know if you have any questions. It is probably a little more involved than the description I provided. +Chris Unity Connection TME From: Ted Nugent [mailto:tednugen...@gmail.com] Sent: Wednesday, January 23, 2013 6:47 PM To: Chris Ward (chrward) Cc: Cisco VoIPoE List Subject: RE: [cisco-voip] Making a message appear anonymous/unknown via single inbox Will do thanks! On Jan 23, 2013 5:57 PM, Chris Ward (chrward) chrw...@cisco.com wrote: Let me try it out in my lab tomorrow and get back to you. Remind me Friday morning if you don’t hear from me. J +Chris Unity Connection TME From: Ted Nugent [mailto:tednugen...@gmail.com] Sent: Wednesday, January 23, 2013 5:09 PM To: Chris Ward (chrward) Cc: Cisco VoIPoE List Subject: Re: [cisco-voip] Making a message appear anonymous/unknown via single inbox Chris thanks for the reply, Yes it is stripping the info washing it through a TP, the phone I'm calling shows Private. While using the TP method I'm basically using the Direct to voicemail (*) VM profile which is CFWDAll to VM on a CTI-RP. For example 7999 is translated to *7999*CTIRPCFwdALL VM However using the Huntpilot way, I have a HP going directly to HL/LG containing the VM Ports and a Directed routing rule going to the subscriber greeting. The HP is configured calling party name/line presention to restricted, same as i did with the TP As mention both have the same affect? This is an SCCP integration with CUC and we get the same results via external calls from an MGCP controlled PRI and SIP/SCCP phones Any thoughts? Thanks Ted On Wed, Jan 23, 2013 at 1:55 PM, Chris Ward (chrward) chrw...@cisco.com wrote: Ted,
Re: [cisco-voip] freeware billing server
Are you talking about CDR? FYI Cisco CDR is in SQL statements, you could just import into MS SQL and run a query to get what you need. You could also look at this: https://uccisco.wordpress.com/2014/05/16/cisco-cdr-call-detail-record-reporting/ Or just get http://www.variphy.com Thank you, Neal Haas Neal Haas IT Analyst, Communications Please report Troubles to the Help Desk. 559-600-5900 Telephone (559) 600-5890 FAX (559) 455-4747 County of Fresno Information Technology Services Division 1020 S Tenth St Fresno, CA 93702 From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Abebe Amare Sent: Tuesday, June 23, 2015 2:26 AM To: cisco voip Subject: [cisco-voip] freeware billing server Hi, I am looking for a freeware billing server for CUCM. Do you guys know any that can do the job? Thanks in advance Abebe ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] Making a message appear anonymous/unknown via single inbox
Apologies for resurrecting an old thread here, but I was curious if there was fixed in more recent versions of Unity Connection. I'm trying this with 10.5(2)su1 with SIP trunk between UCM and UCXN and having the problem where UCXN ignores the restriction settings configured on CUCM. I'm thinking maybe I could make a LUA script on the UCM sip trunk to UCXN, but looking for an easier solution. In my situation, I have certain callers that want to have their CLID blocked. So it is based on the placing the call, not the phone that receives the call and I think this prevents me from using the two options discussed here earlier. Justin On Thu, Jan 24, 2013 at 4:28 PM, Ted Nugent tednugen...@gmail.com wrote: Thanks Chris I like option 2 as well since they only have 24 ports as it stands. I'll give it a shot and let you know how it turns out. Thanks again! On Thu, Jan 24, 2013 at 3:16 PM, Chris Ward (chrward) chrw...@cisco.com wrote: Hi Ted, Seems like you are hitting some known limitations. The settings in CUCM for restricting Calling Party Information don’t really eliminate it, it seems to just mark it as “Restricted” so the information remains and CUC seems hell-bent on finding calling party information. I did find 2 solutions for you, both of which use SIP: 1) Setup an additional integration between CUCM and CUC that is meant only for this anonymous line. In the SIP trunk config, you have to uncheck the “Remote-Party-Id” under the “Call Routing Information” section and make sure “Calling Line ID Presentation” is set to Restricted under the “Outbound Calls” section. This will result in an “Unknown CallerID” message in Outlook. 2) Setup a Loopback SIP trunk for calls to this specific Anonymous DID. You only need one SIP trunk to point to CUCMs own IP address, it acts as the outbound and inbound SIP trunk in this scenario. Under the “Outbound Calls” section, you would need define a Calling Party Transformation CSS that would have access to a transformation pattern that matches all Calling parties (remembering that only calls to this anonymous DID are affected) and mask the calling party with some obscure mask like or you can put a . at the end of the pattern you match and then drop all pre-dot if you want it blank. On the route pattern that points to this loopback SIP trunk, you would modify the called party so that once the call re-enters CUCM, it will be destined for the *7999 number (pulled from you example before) and continues through the normal process to be forwarded to voicemail. Neither solution is super-attractive, but both will work. I personally like #2 since it means you won’t have split up your CUC ports for a separate SIP integration. Let me know if you have any questions. It is probably a little more involved than the description I provided. +Chris Unity Connection TME *From:* Ted Nugent [mailto:tednugen...@gmail.com] *Sent:* Wednesday, January 23, 2013 6:47 PM *To:* Chris Ward (chrward) *Cc:* Cisco VoIPoE List *Subject:* RE: [cisco-voip] Making a message appear anonymous/unknown via single inbox Will do thanks! On Jan 23, 2013 5:57 PM, Chris Ward (chrward) chrw...@cisco.com wrote: Let me try it out in my lab tomorrow and get back to you. Remind me Friday morning if you don’t hear from me. J +Chris Unity Connection TME *From:* Ted Nugent [mailto:tednugen...@gmail.com] *Sent:* Wednesday, January 23, 2013 5:09 PM *To:* Chris Ward (chrward) *Cc:* Cisco VoIPoE List *Subject:* Re: [cisco-voip] Making a message appear anonymous/unknown via single inbox Chris thanks for the reply, Yes it is stripping the info washing it through a TP, the phone I'm calling shows Private. While using the TP method I'm basically using the Direct to voicemail (*) VM profile which is CFWDAll to VM on a CTI-RP. For example 7999 is translated to *7999*CTIRPCFwdALL VM However using the Huntpilot way, I have a HP going directly to HL/LG containing the VM Ports and a Directed routing rule going to the subscriber greeting. The HP is configured calling party name/line presention to restricted, same as i did with the TP As mention both have the same affect? This is an SCCP integration with CUC and we get the same results via external calls from an MGCP controlled PRI and SIP/SCCP phones Any thoughts? Thanks Ted On Wed, Jan 23, 2013 at 1:55 PM, Chris Ward (chrward) chrw...@cisco.com wrote: Ted, Removing the calling party information from the call before it gets to CUC is definitely the way to do this. So, I think you are on the right track. Now, as to why it’s not working, there are a few things you could try. As a test, I would setup a translation pattern to strip the calling information and then forward it to your desk phone (making sure you don’t receive calling party information) so you can make sure that the translation pattern is doing what you think it is.
Re: [cisco-voip] Making a message appear anonymous/unknown via single inbox
in addition to the PSTN, they also want to have caller id blocked on calls on-net to other Cisco phones. So we have certain CSS on Cisco phones that route calls through translation patterns to set the restricted CLID flag before the call rings the other Cisco phones.When we do this, the Cisco phone called party does see 'Private' but if they don't answer the call and it goes into voicemail then the voicemail message will still show the calling party number. On Tue, Jun 23, 2015 at 11:12 AM, Ryan Huff ryanh...@outlook.com wrote: Justin, For clarification, you have a user(s) that makes an outbound call from call manager to the pstn (via a sip trunk to an itsp?) And some of them want to block their Caller ID or mask it to anon? Thanks, Ryan Original Message From: Justin Steinberg jsteinb...@gmail.com Sent: Tuesday, June 23, 2015 11:06 AM To: Ted Nugent tednugen...@gmail.com Subject: Re: [cisco-voip] Making a message appear anonymous/unknown via single inbox CC: Cisco VoIPoE List cisco-voip@puck.nether.net Apologies for resurrecting an old thread here, but I was curious if there was fixed in more recent versions of Unity Connection. I'm trying this with 10.5(2)su1 with SIP trunk between UCM and UCXN and having the problem where UCXN ignores the restriction settings configured on CUCM. I'm thinking maybe I could make a LUA script on the UCM sip trunk to UCXN, but looking for an easier solution. In my situation, I have certain callers that want to have their CLID blocked. So it is based on the placing the call, not the phone that receives the call and I think this prevents me from using the two options discussed here earlier. Justin On Thu, Jan 24, 2013 at 4:28 PM, Ted Nugent tednugen...@gmail.com wrote: Thanks Chris I like option 2 as well since they only have 24 ports as it stands. I'll give it a shot and let you know how it turns out. Thanks again! On Thu, Jan 24, 2013 at 3:16 PM, Chris Ward (chrward) chrw...@cisco.com wrote: Hi Ted, Seems like you are hitting some known limitations. The settings in CUCM for restricting Calling Party Information don’t really eliminate it, it seems to just mark it as “Restricted” so the information remains and CUC seems hell-bent on finding calling party information. I did find 2 solutions for you, both of which use SIP: 1) Setup an additional integration between CUCM and CUC that is meant only for this anonymous line. In the SIP trunk config, you have to uncheck the “Remote-Party-Id” under the “Call Routing Information” section and make sure “Calling Line ID Presentation” is set to Restricted under the “Outbound Calls” section. This will result in an “Unknown CallerID” message in Outlook. 2) Setup a Loopback SIP trunk for calls to this specific Anonymous DID. You only need one SIP trunk to point to CUCMs own IP address, it acts as the outbound and inbound SIP trunk in this scenario. Under the “Outbound Calls” section, you would need define a Calling Party Transformation CSS that would have access to a transformation pattern that matches all Calling parties (remembering that only calls to this anonymous DID are affected) and mask the calling party with some obscure mask like or you can put a . at the end of the pattern you match and then drop all pre-dot if you want it blank. On the route pattern that points to this loopback SIP trunk, you would modify the called party so that once the call re-enters CUCM, it will be destined for the *7999 number (pulled from you example before) and continues through the normal process to be forwarded to voicemail. Neither solution is super-attractive, but both will work. I personally like #2 since it means you won’t have split up your CUC ports for a separate SIP integration. Let me know if you have any questions. It is probably a little more involved than the description I provided. +Chris Unity Connection TME *From:* Ted Nugent [mailto:tednugen...@gmail.com] *Sent:* Wednesday, January 23, 2013 6:47 PM *To:* Chris Ward (chrward) *Cc:* Cisco VoIPoE List *Subject:* RE: [cisco-voip] Making a message appear anonymous/unknown via single inbox Will do thanks! On Jan 23, 2013 5:57 PM, Chris Ward (chrward) chrw...@cisco.com wrote: Let me try it out in my lab tomorrow and get back to you. Remind me Friday morning if you don’t hear from me. J +Chris Unity Connection TME *From:* Ted Nugent [mailto:tednugen...@gmail.com] *Sent:* Wednesday, January 23, 2013 5:09 PM *To:* Chris Ward (chrward) *Cc:* Cisco VoIPoE List *Subject:* Re: [cisco-voip] Making a message appear anonymous/unknown via single inbox Chris thanks for the reply, Yes it is stripping the info washing it through a TP, the phone I'm calling shows Private. While using the TP method I'm basically using the Direct to voicemail (*) VM profile which is CFWDAll to VM on a CTI-RP. For example 7999 is translated to
Re: [cisco-voip] isdn channels full message
not tested, theoretically sound, YMMV. No guarantees, warranties, etc. use a route group with top down hunting. your real gateways are the first entries. last entry is an h323 gateway. the destination IP is the local CM. This is essentially a loopback going out/in the IP interface. Use the CSS for that gateway to match translation patterns that overwrite the called party number to be the DN that forwards to Voicemail. Also use a different egress CSS for the TP. Setup your VMail system to answer based on that redirect number and deliver whatever message you want. -w On Jun 23, 2015, at 9:15 AM, Ryan Huff ryanh...@outlook.commailto:ryanh...@outlook.com wrote: Ah okay Well, an easy way would be MGCP Gateways and route groups (and just mux the timers to get quick failover). With H.323 however, that is a bit more tricky because CCM knows nothing about the gateway or PRI's state, so if you could do anything, it would have to be in the gateway. You can use hunt groups in an h.323 IOS gateway to do this with multiple PRI's; you may be able to do this by having one of the peers in the hunt group kick the call back into CCM to a destination that forwards to voicemail. Thanks, Ryan From: abba...@gmail.commailto:abba...@gmail.com To: ryanh...@outlook.commailto:ryanh...@outlook.com; cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net Subject: RE: [cisco-voip] isdn channels full message Date: Tue, 23 Jun 2015 13:55:42 +0100 Hi just to add it to. We need it only for the outbound direction. From: Ryan Huff [mailto:ryanh...@outlook.com] Sent: 23 June 2015 13:51 To: abbas wali; cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net Subject: RE: [cisco-voip] isdn channels full message I don't believe so, at least not on the CPE side. The presence of all channels being busy would indicate that there aren't any channels available for the next call (or the next call after all channels are busy) to ring through the PRI for you to forward to voicemail, even if there were a way for you to act upon channel utilization. If you are trying to use conditional routing based on full PRI capacity, you'd probably have to work with your carrier and see if they can forward upon full channel utilization (they have the capability to do that, but will they is the question). However, they wouldn't be able to forward through the utilized PRI in that scenario, they'd have to forward to an alternate number. Thanks, Ryan From: abba...@gmail.commailto:abba...@gmail.com To: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net Date: Tue, 23 Jun 2015 11:38:55 +0100 Subject: [cisco-voip] isdn channels full message Hi folks, CUCM 9 and H323 gateways with ISDN channels to PSTN. We want to redirect to VM when all the channels are full. Can CUCM do it or Dpeer? Thanks ___ cisco-voip mailing list cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] isdn channels full message
Ah okay Well, an easy way would be MGCP Gateways and route groups (and just mux the timers to get quick failover). With H.323 however, that is a bit more tricky because CCM knows nothing about the gateway or PRI's state, so if you could do anything, it would have to be in the gateway. You can use hunt groups in an h.323 IOS gateway to do this with multiple PRI's; you may be able to do this by having one of the peers in the hunt group kick the call back into CCM to a destination that forwards to voicemail. Thanks, Ryan From: abba...@gmail.com To: ryanh...@outlook.com; cisco-voip@puck.nether.net Subject: RE: [cisco-voip] isdn channels full message Date: Tue, 23 Jun 2015 13:55:42 +0100 Hi just to add it to. We need it only for the outbound direction. From: Ryan Huff [mailto:ryanh...@outlook.com] Sent: 23 June 2015 13:51 To: abbas wali; cisco-voip@puck.nether.net Subject: RE: [cisco-voip] isdn channels full message I don't believe so, at least not on the CPE side. The presence of all channels being busy would indicate that there aren't any channels available for the next call (or the next call after all channels are busy) to ring through the PRI for you to forward to voicemail, even if there were a way for you to act upon channel utilization. If you are trying to use conditional routing based on full PRI capacity, you'd probably have to work with your carrier and see if they can forward upon full channel utilization (they have the capability to do that, but will they is the question). However, they wouldn't be able to forward through the utilized PRI in that scenario, they'd have to forward to an alternate number. Thanks, RyanFrom: abba...@gmail.com To: cisco-voip@puck.nether.net Date: Tue, 23 Jun 2015 11:38:55 +0100 Subject: [cisco-voip] isdn channels full messageHi folks, CUCM 9 and H323 gateways with ISDN channels to PSTN. We want to redirect to VM when all the channels are full. Can CUCM do it or Dpeer? Thanks ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] isdn channels full message
I've done this before. You can use a SIP trunk to CUCM as well. The way I do it is have it as a different route group so you can manipulate the dialed number right in the route list config. On Tue, Jun 23, 2015 at 11:47 AM, Wes Sisk (wsisk) ws...@cisco.com wrote: not tested, theoretically sound, YMMV. No guarantees, warranties, etc. use a route group with top down hunting. your real gateways are the first entries. last entry is an h323 gateway. the destination IP is the local CM. This is essentially a loopback going out/in the IP interface. Use the CSS for that gateway to match translation patterns that overwrite the called party number to be the DN that forwards to Voicemail. Also use a different egress CSS for the TP. Setup your VMail system to answer based on that redirect number and deliver whatever message you want. -w On Jun 23, 2015, at 9:15 AM, Ryan Huff ryanh...@outlook.com wrote: Ah okay Well, an easy way would be MGCP Gateways and route groups (and just mux the timers to get quick failover). With H.323 however, that is a bit more tricky because CCM knows nothing about the gateway or PRI's state, so if you could do anything, it would have to be in the gateway. You can use hunt groups in an h.323 IOS gateway to do this with multiple PRI's; you may be able to do this by having one of the peers in the hunt group kick the call back into CCM to a destination that forwards to voicemail. Thanks, Ryan -- From: abba...@gmail.com To: ryanh...@outlook.com; cisco-voip@puck.nether.net Subject: RE: [cisco-voip] isdn channels full message Date: Tue, 23 Jun 2015 13:55:42 +0100 Hi just to add it to. We need it only for the outbound direction. *From:* Ryan Huff [mailto:ryanh...@outlook.com ryanh...@outlook.com] *Sent:* 23 June 2015 13:51 *To:* abbas wali; cisco-voip@puck.nether.net *Subject:* RE: [cisco-voip] isdn channels full message I don't believe so, at least not on the CPE side. The presence of all channels being busy would indicate that there aren't any channels available for the next call (or the next call after all channels are busy) to ring through the PRI for you to forward to voicemail, even if there were a way for you to act upon channel utilization. If you are trying to use conditional routing based on full PRI capacity, you'd probably have to work with your carrier and see if they can forward upon full channel utilization (they have the capability to do that, but will they is the question). However, they wouldn't be able to forward through the utilized PRI in that scenario, they'd have to forward to an alternate number. Thanks, Ryan -- From: abba...@gmail.com To: cisco-voip@puck.nether.net Date: Tue, 23 Jun 2015 11:38:55 +0100 Subject: [cisco-voip] isdn channels full message Hi folks, CUCM 9 and H323 gateways with ISDN channels to PSTN. We want to redirect to VM when all the channels are full. Can CUCM do it or Dpeer? Thanks ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
[cisco-voip] CME w/ SIP Trunk
Hello! I'm trying to get a SIP trunk out to a regional SP (Lumos) configured. I need to get CME setup to register numbers with their sip proxy, but the registration is not happening and i'm not seeing any register messages debugs from debug ccsip messages to troubleshoot from. So I think maybe CME isn't trying? What should trigger CME to try and register these numbers? My config looks like this (some ephones/ephone-dns up and registered) - authentication credentials were provided from Lumos. IOS 15.4(3)M2 msu-tmp-access#sh run | s sip-ua sip-ua credentials username 304-929-0300 password 7 blah realm sbc.ia.ntelos.net authentication username 304-929-0300 password 7 blah retry register 10 registrar dns:sbc.ia.ntelos.net:5060 expires 120 sip-server dns:sbc.ia.ntelos.net:5060 ! msu-tmp-access#sho run | s voice service voice service voip ip address trusted list ipv4 216.12.114.195 address-hiding allow-connections sip to sip fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none sip bind control source-interface GigabitEthernet0/2 bind media source-interface GigabitEthernet0/2 registrar server options-ping 60 -- Ed Leatherman ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CME w/ SIP Trunk
What do you see for show sip-ua register status? Are you sure the gateway can resolve the sip-server via DNS? On Tue, Jun 23, 2015 at 2:32 PM, Ed Leatherman ealeather...@gmail.com wrote: Hello! I'm trying to get a SIP trunk out to a regional SP (Lumos) configured. I need to get CME setup to register numbers with their sip proxy, but the registration is not happening and i'm not seeing any register messages debugs from debug ccsip messages to troubleshoot from. So I think maybe CME isn't trying? What should trigger CME to try and register these numbers? My config looks like this (some ephones/ephone-dns up and registered) - authentication credentials were provided from Lumos. IOS 15.4(3)M2 msu-tmp-access#sh run | s sip-ua sip-ua credentials username 304-929-0300 password 7 blah realm sbc.ia.ntelos.net authentication username 304-929-0300 password 7 blah retry register 10 registrar dns:sbc.ia.ntelos.net:5060 expires 120 sip-server dns:sbc.ia.ntelos.net:5060 ! msu-tmp-access#sho run | s voice service voice service voip ip address trusted list ipv4 216.12.114.195 address-hiding allow-connections sip to sip fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none sip bind control source-interface GigabitEthernet0/2 bind media source-interface GigabitEthernet0/2 registrar server options-ping 60 -- Ed Leatherman ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CME w/ SIP Trunk
Brian msu-tmp-access#sho sip-ua register status Line peer expires(sec) reg survival P-Associ-URI == === 2031120001 43 no normal 2031220003 43 no normal 2031320005 43 no normal 2031420007 43 no normal .. etc .. all no I can ping the sip-server from router so it appears to be able to resolve the name OK. On Tue, Jun 23, 2015 at 2:48 PM, Brian Meade bmead...@vt.edu wrote: What do you see for show sip-ua register status? Are you sure the gateway can resolve the sip-server via DNS? On Tue, Jun 23, 2015 at 2:32 PM, Ed Leatherman ealeather...@gmail.com wrote: Hello! I'm trying to get a SIP trunk out to a regional SP (Lumos) configured. I need to get CME setup to register numbers with their sip proxy, but the registration is not happening and i'm not seeing any register messages debugs from debug ccsip messages to troubleshoot from. So I think maybe CME isn't trying? What should trigger CME to try and register these numbers? My config looks like this (some ephones/ephone-dns up and registered) - authentication credentials were provided from Lumos. IOS 15.4(3)M2 msu-tmp-access#sh run | s sip-ua sip-ua credentials username 304-929-0300 password 7 blah realm sbc.ia.ntelos.net authentication username 304-929-0300 password 7 blah retry register 10 registrar dns:sbc.ia.ntelos.net:5060 expires 120 sip-server dns:sbc.ia.ntelos.net:5060 ! msu-tmp-access#sho run | s voice service voice service voip ip address trusted list ipv4 216.12.114.195 address-hiding allow-connections sip to sip fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none sip bind control source-interface GigabitEthernet0/2 bind media source-interface GigabitEthernet0/2 registrar server options-ping 60 -- Ed Leatherman ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip -- Ed Leatherman ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CME w/ SIP Trunk
How about connecting via telnet over 5060? You may be having a TCP issue which is why you never see the Register sent. On Tue, Jun 23, 2015 at 3:09 PM, Ed Leatherman ealeather...@gmail.com wrote: Brian msu-tmp-access#sho sip-ua register status Line peer expires(sec) reg survival P-Associ-URI == === 2031120001 43 no normal 2031220003 43 no normal 2031320005 43 no normal 2031420007 43 no normal .. etc .. all no I can ping the sip-server from router so it appears to be able to resolve the name OK. On Tue, Jun 23, 2015 at 2:48 PM, Brian Meade bmead...@vt.edu wrote: What do you see for show sip-ua register status? Are you sure the gateway can resolve the sip-server via DNS? On Tue, Jun 23, 2015 at 2:32 PM, Ed Leatherman ealeather...@gmail.com wrote: Hello! I'm trying to get a SIP trunk out to a regional SP (Lumos) configured. I need to get CME setup to register numbers with their sip proxy, but the registration is not happening and i'm not seeing any register messages debugs from debug ccsip messages to troubleshoot from. So I think maybe CME isn't trying? What should trigger CME to try and register these numbers? My config looks like this (some ephones/ephone-dns up and registered) - authentication credentials were provided from Lumos. IOS 15.4(3)M2 msu-tmp-access#sh run | s sip-ua sip-ua credentials username 304-929-0300 password 7 blah realm sbc.ia.ntelos.net authentication username 304-929-0300 password 7 blah retry register 10 registrar dns:sbc.ia.ntelos.net:5060 expires 120 sip-server dns:sbc.ia.ntelos.net:5060 ! msu-tmp-access#sho run | s voice service voice service voip ip address trusted list ipv4 216.12.114.195 address-hiding allow-connections sip to sip fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none sip bind control source-interface GigabitEthernet0/2 bind media source-interface GigabitEthernet0/2 registrar server options-ping 60 -- Ed Leatherman ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip -- Ed Leatherman ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] isdn channels full message
Ryan, It's possible to do it but sometimes requires some reconfiguration. H.323 gateways typically send back a user busy I believe when all of the dial-peers run out of ports. So you need to change CallManager service parameter to keep routing on user busy or configure no dial-peer outbound status-check pots on the gateway. Brian On Tue, Jun 23, 2015 at 3:27 PM, Ryan Huff ryanh...@outlook.com wrote: Wes, I tried something like this before with h.323 (full disclosure, it was ccm 8.0.3) and the behavior I experienced was that on the busy out of the first gateway (the primary), call manager did not the recall the call and try the next member in the group, it just busied on the first h.323 gateway (using top-down). Sort of like a release to switch rather than a supervised transfer. Do you think I had something mis-configured (timers ... etc) or something? I want to lab this up tonight, cause it will solve a problem of mine if it works :). Thanks! Thanks, Ryan (the forever student) Original Message From: Wes Sisk (wsisk) ws...@cisco.com Sent: Tuesday, June 23, 2015 11:47 AM To: abbas wali abba...@gmail.com Subject: Re: [cisco-voip] isdn channels full message CC: cisco-voip@puck.nether.net,Ryan Huff ryanh...@outlook.com not tested, theoretically sound, YMMV. No guarantees, warranties, etc. use a route group with top down hunting. your real gateways are the first entries. last entry is an h323 gateway. the destination IP is the local CM. This is essentially a loopback going out/in the IP interface. Use the CSS for that gateway to match translation patterns that overwrite the called party number to be the DN that forwards to Voicemail. Also use a different egress CSS for the TP. Setup your VMail system to answer based on that redirect number and deliver whatever message you want. -w On Jun 23, 2015, at 9:15 AM, Ryan Huff ryanh...@outlook.com wrote: Ah okay Well, an easy way would be MGCP Gateways and route groups (and just mux the timers to get quick failover). With H.323 however, that is a bit more tricky because CCM knows nothing about the gateway or PRI's state, so if you could do anything, it would have to be in the gateway. You can use hunt groups in an h.323 IOS gateway to do this with multiple PRI's; you may be able to do this by having one of the peers in the hunt group kick the call back into CCM to a destination that forwards to voicemail. Thanks, Ryan -- From: abba...@gmail.com To: ryanh...@outlook.com; cisco-voip@puck.nether.net Subject: RE: [cisco-voip] isdn channels full message Date: Tue, 23 Jun 2015 13:55:42 +0100 Hi just to add it to. We need it only for the outbound direction. *From:* Ryan Huff [mailto:ryanh...@outlook.com ryanh...@outlook.com] *Sent:* 23 June 2015 13:51 *To:* abbas wali; cisco-voip@puck.nether.net *Subject:* RE: [cisco-voip] isdn channels full message I don't believe so, at least not on the CPE side. The presence of all channels being busy would indicate that there aren't any channels available for the next call (or the next call after all channels are busy) to ring through the PRI for you to forward to voicemail, even if there were a way for you to act upon channel utilization. If you are trying to use conditional routing based on full PRI capacity, you'd probably have to work with your carrier and see if they can forward upon full channel utilization (they have the capability to do that, but will they is the question). However, they wouldn't be able to forward through the utilized PRI in that scenario, they'd have to forward to an alternate number. Thanks, Ryan -- From: abba...@gmail.com To: cisco-voip@puck.nether.net Date: Tue, 23 Jun 2015 11:38:55 +0100 Subject: [cisco-voip] isdn channels full message Hi folks, CUCM 9 and H323 gateways with ISDN channels to PSTN. We want to redirect to VM when all the channels are full. Can CUCM do it or Dpeer? Thanks ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CME w/ SIP Trunk
I'd try the username without the dashes first. On Tue, Jun 23, 2015 at 3:26 PM, Ed Leatherman ealeather...@gmail.com wrote: I did a packet cap and we are sending the SIP REGISTER, but its not showing up in sip debug?? really weird. anywhere I'm not binding SIP to my loopback address, i'm not getting SIP debugs for. So I am getting 403 back from SP after all, gonna double check username/passwords On Tue, Jun 23, 2015 at 3:16 PM, Brian Meade bmead...@vt.edu wrote: How about connecting via telnet over 5060? You may be having a TCP issue which is why you never see the Register sent. On Tue, Jun 23, 2015 at 3:09 PM, Ed Leatherman ealeather...@gmail.com wrote: Brian msu-tmp-access#sho sip-ua register status Line peer expires(sec) reg survival P-Associ-URI == === 2031120001 43 no normal 2031220003 43 no normal 2031320005 43 no normal 2031420007 43 no normal .. etc .. all no I can ping the sip-server from router so it appears to be able to resolve the name OK. On Tue, Jun 23, 2015 at 2:48 PM, Brian Meade bmead...@vt.edu wrote: What do you see for show sip-ua register status? Are you sure the gateway can resolve the sip-server via DNS? On Tue, Jun 23, 2015 at 2:32 PM, Ed Leatherman ealeather...@gmail.com wrote: Hello! I'm trying to get a SIP trunk out to a regional SP (Lumos) configured. I need to get CME setup to register numbers with their sip proxy, but the registration is not happening and i'm not seeing any register messages debugs from debug ccsip messages to troubleshoot from. So I think maybe CME isn't trying? What should trigger CME to try and register these numbers? My config looks like this (some ephones/ephone-dns up and registered) - authentication credentials were provided from Lumos. IOS 15.4(3)M2 msu-tmp-access#sh run | s sip-ua sip-ua credentials username 304-929-0300 password 7 blah realm sbc.ia.ntelos.net authentication username 304-929-0300 password 7 blah retry register 10 registrar dns:sbc.ia.ntelos.net:5060 expires 120 sip-server dns:sbc.ia.ntelos.net:5060 ! msu-tmp-access#sho run | s voice service voice service voip ip address trusted list ipv4 216.12.114.195 address-hiding allow-connections sip to sip fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none sip bind control source-interface GigabitEthernet0/2 bind media source-interface GigabitEthernet0/2 registrar server options-ping 60 -- Ed Leatherman ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip -- Ed Leatherman -- Ed Leatherman ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] isdn channels full message
That is probably it. Thanks Brian! Thanks, Ryan Original Message From: Brian Meade bmead...@vt.edu Sent: Tuesday, June 23, 2015 03:34 PM To: Ryan Huff ryanh...@outlook.com Subject: Re: [cisco-voip] isdn channels full message CC: Wes Sisk (wsisk) ws...@cisco.com,abbas Wali abba...@gmail.com,cisco-voip@puck.nether.net Ryan, It's possible to do it but sometimes requires some reconfiguration. H.323 gateways typically send back a user busy I believe when all of the dial-peers run out of ports. So you need to change CallManager service parameter to keep routing on user busy or configure no dial-peer outbound status-check pots on the gateway. Brian On Tue, Jun 23, 2015 at 3:27 PM, Ryan Huff ryanh...@outlook.com wrote: Wes, I tried something like this before with h.323 (full disclosure, it was ccm 8.0.3) and the behavior I experienced was that on the busy out of the first gateway (the primary), call manager did not the recall the call and try the next member in the group, it just busied on the first h.323 gateway (using top-down). Sort of like a release to switch rather than a supervised transfer. Do you think I had something mis-configured (timers ... etc) or something? I want to lab this up tonight, cause it will solve a problem of mine if it works :). Thanks! Thanks, Ryan (the forever student) Original Message From: Wes Sisk (wsisk) ws...@cisco.com Sent: Tuesday, June 23, 2015 11:47 AM To: abbas wali abba...@gmail.com Subject: Re: [cisco-voip] isdn channels full message CC: cisco-voip@puck.nether.net,Ryan Huff ryanh...@outlook.com not tested, theoretically sound, YMMV. No guarantees, warranties, etc. use a route group with top down hunting. your real gateways are the first entries. last entry is an h323 gateway. the destination IP is the local CM. This is essentially a loopback going out/in the IP interface. Use the CSS for that gateway to match translation patterns that overwrite the called party number to be the DN that forwards to Voicemail. Also use a different egress CSS for the TP. Setup your VMail system to answer based on that redirect number and deliver whatever message you want. -w On Jun 23, 2015, at 9:15 AM, Ryan Huff ryanh...@outlook.com wrote: Ah okay Well, an easy way would be MGCP Gateways and route groups (and just mux the timers to get quick failover). With H.323 however, that is a bit more tricky because CCM knows nothing about the gateway or PRI's state, so if you could do anything, it would have to be in the gateway. You can use hunt groups in an h.323 IOS gateway to do this with multiple PRI's; you may be able to do this by having one of the peers in the hunt group kick the call back into CCM to a destination that forwards to voicemail. Thanks, Ryan -- From: abba...@gmail.com To: ryanh...@outlook.com; cisco-voip@puck.nether.net Subject: RE: [cisco-voip] isdn channels full message Date: Tue, 23 Jun 2015 13:55:42 +0100 Hi just to add it to. We need it only for the outbound direction. *From:* Ryan Huff [mailto:ryanh...@outlook.com ryanh...@outlook.com] *Sent:* 23 June 2015 13:51 *To:* abbas wali; cisco-voip@puck.nether.net *Subject:* RE: [cisco-voip] isdn channels full message I don't believe so, at least not on the CPE side. The presence of all channels being busy would indicate that there aren't any channels available for the next call (or the next call after all channels are busy) to ring through the PRI for you to forward to voicemail, even if there were a way for you to act upon channel utilization. If you are trying to use conditional routing based on full PRI capacity, you'd probably have to work with your carrier and see if they can forward upon full channel utilization (they have the capability to do that, but will they is the question). However, they wouldn't be able to forward through the utilized PRI in that scenario, they'd have to forward to an alternate number. Thanks, Ryan -- From: abba...@gmail.com To: cisco-voip@puck.nether.net Date: Tue, 23 Jun 2015 11:38:55 +0100 Subject: [cisco-voip] isdn channels full message Hi folks, CUCM 9 and H323 gateways with ISDN channels to PSTN. We want to redirect to VM when all the channels are full. Can CUCM do it or Dpeer? Thanks ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net
Re: [cisco-voip] isdn channels full message
That is probably it. Thanks Brian! Thanks, Ryan Original Message From: Brian Meade bmead...@vt.edu Sent: Tuesday, June 23, 2015 03:34 PM To: Ryan Huff ryanh...@outlook.com Subject: Re: [cisco-voip] isdn channels full message CC: Wes Sisk (wsisk) ws...@cisco.com,abbas Wali abba...@gmail.com,cisco-voip@puck.nether.net Ryan, It's possible to do it but sometimes requires some reconfiguration. H.323 gateways typically send back a user busy I believe when all of the dial-peers run out of ports. So you need to change CallManager service parameter to keep routing on user busy or configure no dial-peer outbound status-check pots on the gateway. Brian On Tue, Jun 23, 2015 at 3:27 PM, Ryan Huff ryanh...@outlook.com wrote: Wes, I tried something like this before with h.323 (full disclosure, it was ccm 8.0.3) and the behavior I experienced was that on the busy out of the first gateway (the primary), call manager did not the recall the call and try the next member in the group, it just busied on the first h.323 gateway (using top-down). Sort of like a release to switch rather than a supervised transfer. Do you think I had something mis-configured (timers ... etc) or something? I want to lab this up tonight, cause it will solve a problem of mine if it works :). Thanks! Thanks, Ryan (the forever student) Original Message From: Wes Sisk (wsisk) ws...@cisco.com Sent: Tuesday, June 23, 2015 11:47 AM To: abbas wali abba...@gmail.com Subject: Re: [cisco-voip] isdn channels full message CC: cisco-voip@puck.nether.net,Ryan Huff ryanh...@outlook.com not tested, theoretically sound, YMMV. No guarantees, warranties, etc. use a route group with top down hunting. your real gateways are the first entries. last entry is an h323 gateway. the destination IP is the local CM. This is essentially a loopback going out/in the IP interface. Use the CSS for that gateway to match translation patterns that overwrite the called party number to be the DN that forwards to Voicemail. Also use a different egress CSS for the TP. Setup your VMail system to answer based on that redirect number and deliver whatever message you want. -w On Jun 23, 2015, at 9:15 AM, Ryan Huff ryanh...@outlook.com wrote: Ah okay Well, an easy way would be MGCP Gateways and route groups (and just mux the timers to get quick failover). With H.323 however, that is a bit more tricky because CCM knows nothing about the gateway or PRI's state, so if you could do anything, it would have to be in the gateway. You can use hunt groups in an h.323 IOS gateway to do this with multiple PRI's; you may be able to do this by having one of the peers in the hunt group kick the call back into CCM to a destination that forwards to voicemail. Thanks, Ryan -- From: abba...@gmail.com To: ryanh...@outlook.com; cisco-voip@puck.nether.net Subject: RE: [cisco-voip] isdn channels full message Date: Tue, 23 Jun 2015 13:55:42 +0100 Hi just to add it to. We need it only for the outbound direction. *From:* Ryan Huff [mailto:ryanh...@outlook.com ryanh...@outlook.com] *Sent:* 23 June 2015 13:51 *To:* abbas wali; cisco-voip@puck.nether.net *Subject:* RE: [cisco-voip] isdn channels full message I don't believe so, at least not on the CPE side. The presence of all channels being busy would indicate that there aren't any channels available for the next call (or the next call after all channels are busy) to ring through the PRI for you to forward to voicemail, even if there were a way for you to act upon channel utilization. If you are trying to use conditional routing based on full PRI capacity, you'd probably have to work with your carrier and see if they can forward upon full channel utilization (they have the capability to do that, but will they is the question). However, they wouldn't be able to forward through the utilized PRI in that scenario, they'd have to forward to an alternate number. Thanks, Ryan -- From: abba...@gmail.com To: cisco-voip@puck.nether.net Date: Tue, 23 Jun 2015 11:38:55 +0100 Subject: [cisco-voip] isdn channels full message Hi folks, CUCM 9 and H323 gateways with ISDN channels to PSTN. We want to redirect to VM when all the channels are full. Can CUCM do it or Dpeer? Thanks ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net
[cisco-voip] isdn channels full message
Hi folks, CUCM 9 and H323 gateways with ISDN channels to PSTN. We want to redirect to VM when all the channels are full. Can CUCM do it or Dpeer? Thanks ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CME w/ SIP Trunk
Didnt seem to help but thats a good thought. Slogging it out with SP tomorrow again. I'm really puzzled about the SIP debugs.. its like i'm not getting all my SIP messages in there On Tue, Jun 23, 2015 at 3:29 PM, Brian Meade bmead...@vt.edu wrote: I'd try the username without the dashes first. On Tue, Jun 23, 2015 at 3:26 PM, Ed Leatherman ealeather...@gmail.com wrote: I did a packet cap and we are sending the SIP REGISTER, but its not showing up in sip debug?? really weird. anywhere I'm not binding SIP to my loopback address, i'm not getting SIP debugs for. So I am getting 403 back from SP after all, gonna double check username/passwords On Tue, Jun 23, 2015 at 3:16 PM, Brian Meade bmead...@vt.edu wrote: How about connecting via telnet over 5060? You may be having a TCP issue which is why you never see the Register sent. On Tue, Jun 23, 2015 at 3:09 PM, Ed Leatherman ealeather...@gmail.com wrote: Brian msu-tmp-access#sho sip-ua register status Line peer expires(sec) reg survival P-Associ-URI == === 2031120001 43 no normal 2031220003 43 no normal 2031320005 43 no normal 2031420007 43 no normal .. etc .. all no I can ping the sip-server from router so it appears to be able to resolve the name OK. On Tue, Jun 23, 2015 at 2:48 PM, Brian Meade bmead...@vt.edu wrote: What do you see for show sip-ua register status? Are you sure the gateway can resolve the sip-server via DNS? On Tue, Jun 23, 2015 at 2:32 PM, Ed Leatherman ealeather...@gmail.com wrote: Hello! I'm trying to get a SIP trunk out to a regional SP (Lumos) configured. I need to get CME setup to register numbers with their sip proxy, but the registration is not happening and i'm not seeing any register messages debugs from debug ccsip messages to troubleshoot from. So I think maybe CME isn't trying? What should trigger CME to try and register these numbers? My config looks like this (some ephones/ephone-dns up and registered) - authentication credentials were provided from Lumos. IOS 15.4(3)M2 msu-tmp-access#sh run | s sip-ua sip-ua credentials username 304-929-0300 password 7 blah realm sbc.ia.ntelos.net authentication username 304-929-0300 password 7 blah retry register 10 registrar dns:sbc.ia.ntelos.net:5060 expires 120 sip-server dns:sbc.ia.ntelos.net:5060 ! msu-tmp-access#sho run | s voice service voice service voip ip address trusted list ipv4 216.12.114.195 address-hiding allow-connections sip to sip fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none sip bind control source-interface GigabitEthernet0/2 bind media source-interface GigabitEthernet0/2 registrar server options-ping 60 -- Ed Leatherman ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip -- Ed Leatherman -- Ed Leatherman -- Ed Leatherman ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
