05-17-2020 03:51 PM
Greetings,
When we use Mobility to transfer a call from a softphone (IP Communicator) to a cell phone, it works fine. However, if we have multiple people on a call (like a conference) and then try to use Mobility to transfer to a cell phone, the call is flagged by AT&T’s Call Protect application (on the cell phone). It looks like this is happening because the outbound caller ID from a Mobility conference call to a cell phone shows up as +1 (000) 062-4220. It is being classified as Spam. I assume this is because of the (000) area code. I contacted AT&T and asked them about removing that number from the Spam list, but they said we would have to prove that we own the number (which we don’t). It seems to be some sort of Cisco internal CUCM generated thing. Do you know if it’s possible to change or set the outgoing caller ID for this number?
Thanks
Solved! Go to Solution.
06-08-2020 01:22 PM - edited 06-08-2020 02:57 PM
It worked!
I used the first one you listed (below).
voice class sip-profiles 10
request ANY sip-header From modify "From: (\"Conference\" <sip:)(.*)" "From: \11023456789@\2"
response ANY sip-header From modify "From: (\"Conference\" <sip:)(.*)" "From: \11023456789@\2"
request ANY sip-header P-Asserted-Identity modify "P-Asserted-Identity: (\"Conference\" <sip:)(.*)" "P-Asserted-Identity: \11023456789@\2"
response ANY sip-header P-Asserted-Identity modify "P-Asserted-Identity: (\"Conference\" <sip:)(.*)" "P-Asserted-Identity: \11023456789@\2"
I then used the following commands to add it.
voice service voip
sip
sip-profiles 10
Now we are able to transfer conference calls via Mobility to AT&T mobile phones using AT&T Call Protect without the call being flagged as Spam. I greatly appreciate your assistance! Thanks.
06-08-2020 10:27 PM
That’s great news Chuck. Glad you got this to work.
Was there any reason for why you tied the SIP profile to global configuration instead of to the outbound dial peer that sends calls to AT&T? Having it set in global configuration can potentially affect other calls that you don’t intended to use the SIP profile for.
06-09-2020 03:56 AM
Just another example of my lack of knowledge, lol.
Can you be more specific of where I should tie it?
06-09-2020 05:07 AM - edited 06-09-2020 05:08 AM
dial-peer voice 110 voip <-Change the dial peer number to fit your setup.
voice-class sip profiles 10
I added this to the first reply where I went through your debug, the one with a masked picture.
06-09-2020 08:44 AM
Here are the existing dial peers. I assume it would be one of the ones I highlighted in red?
dial-peer voice 101 voip
description ***from ATT***
translation-profile incoming att-to-cube
session protocol sipv2
incoming uri via 11
voice-class codec 4
voice-class sip asymmetric payload full
voice-class sip privacy-policy passthru
voice-class sip profiles 3 inbound
dtmf-relay rtp-nte
fax-relay ecm disable
fax rate 14400
fax nsf 000000
no vad
!
dial-peer voice 102 voip
description ***from CUCMs***
translation-profile incoming cucm-to-cube
session protocol sipv2
incoming uri via 22
voice-class codec 4
dtmf-relay rtp-nte
fax-relay ecm disable
fax rate 14400
fax nsf 000000
no vad
!
dial-peer voice 201 voip
description ***to ATT***
translation-profile outgoing cube-to-att
destination-pattern ^9T
session protocol sipv2
session server-group 201
voice-class codec 5
voice-class sip asymmetric payload full
voice-class sip asserted-id pai
voice-class sip privacy-policy passthru
voice-class sip options-keepalive
dtmf-relay rtp-nte
fax-relay ecm disable
fax rate 14400
fax nsf 000000
no vad
!
dial-peer voice 202 voip
description ***to CUCMs***
destination-pattern [1-8]...
session protocol sipv2
session server-group 202
voice-class codec 4
voice-class sip asymmetric payload full
voice-class sip privacy-policy passthru
dtmf-relay rtp-nte
fax-relay ecm disable
fax rate 14400
fax nsf 000000
no vad
06-09-2020 11:35 AM - edited 06-09-2020 11:52 AM
This would be your outbound dial peer to AT&T.
dial-peer voice 201 voip
It even says so in the description. “description ***to ATT***”
06-09-2020 12:48 PM
Yes, I saw that. I guess my question was what's the difference between "from CUCMs" and "to ATT". Originally I was thinking all traffic coming from CUCM would be going to ATT, but then I realized "from CUCMs" is probably the unmodified traffic coming into the router (ingress), whereas, "to ATT" is the traffic leaving the router (egress). I have applied it to dial-peer 201. Thanks.
06-09-2020 01:29 PM
That absolutely correctly understood. There is always two legs for each call. One ingress to the router and one egress from it. Dial peers don’t have a direction as such, they become inbound or outbound based on configuration or could be used for both directions. It all depends on the preference of the person setting up the configuration. Personally I prefer to have individual dial peer for each direction as it makes it easier and clearer to see the direction of the calls and there are more room for specific configuration in each direction. Others likely have different opinions on this, rightly so as it’s in each person’s perspective what works for them.
06-08-2020 12:50 PM
You can test the SIP profile with this tool. https://cway.cisco.com/tools/SipProfileTest/
06-08-2020 02:44 PM
Thanks.
05-18-2020 06:21 AM
05-18-2020 09:47 AM
We are not utilizing a specific conference bridge number. We are either initiating multiple calls, then "joining" (pressing the conference button) or answering incoming calls and then joining them.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide