06-28-2022 08:36 AM
Our PSTN provider only allows outbound calls that validate either by being a DID we own, or if we pass along a validated number in the SIP header. We had this in place for a situation where we needed to send a toll free number as the caller ID for a direct outbound call, but it does not seem to apply to SNR calls. (* is to mask numbers):
request INVITE sip-header Diversion add "Diversion:\"ABC Company \"<sip:+1571361*****@10.255.255.254>;reason=unconditional;privacy=off;screen=yes"
With SNR, the caller ID that is sent to the remote destination is the number of the original CALLED party (the number that was diverted). Is there a rule I can write to send the the original CALLING party number to the remote destination? And, if so, can I do this only for one particular originally dialed number?
Thanks in advance for your support.
Solved! Go to Solution.
06-29-2022 11:58 AM - edited 06-29-2022 12:24 PM
All, I figured out my solution on my own. The original post was to be a two part question. It turns out my diversion header was working just as it was supposed to, using the called destination profile, an owned DID, as the diversion header (that which is supported by my provider). This was just a brain cramp on my part.
Part two of the question was going to be, how can I send the original CALLED party number for a single remote destination/SNR profile, but leave the CALLING party for all other SNR profiles. This I can and did accomplish using a calling party transformation pattern to mask the calling party with the original called party DN.
Thank you so much for your replies. I think in checking what you, @Daniel Bosch, posted made me realize my gateway/trunk configuration is solid for most normal scenarios and I needed to think differently.
06-28-2022 12:22 PM
Please share the output of debug ccsip message for a SNR call.
06-28-2022 02:36 PM - edited 06-28-2022 02:41 PM
Stephanie,
Have you checked with your ITSP to see what they require to pass the original calling party? Some SIP carriers just need the Diversion header with a number matching an owned DID. Checking the "Redirecting Diversion Header Delivery - Inbound" box in the Inbound Call section of the CUCM SIP Trunk is usually sufficient to accomplish this (depending on your DN format.)
** Others want you to modify the PAI header (P-Asserted-Identity) as shown below. I typically use the BTN, or main# on the trunk.
Some carriers even want BOTH Diversion and modified PAI, but isn't common.
The caveat is that some carriers will use the PAI value as the ANI / calling# instead of what is in the From header, so it's wise to find out what your carrier wants to see on redirects before you apply any changes.
Example:
voice class sip-profiles 101
request ANY sip-header P-Asserted-Identity modify "P-Asserted-Identity:(.*<)sip:(.*)" "P-Asserted-Identity:\1sip:5125551234@sip.domain.com>"
dial-peer voice 101 voip
description *** Outbound to ITSP ***
translation-profile outgoing ITSPout
destination-pattern 91[2-9]..[2-9]......$
no modem passthrough
session protocol sipv2
session target sip-server
voice-class sip profiles 101 <--- apply to outbound peer
voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0
dtmf-relay rtp-nte
codec g711ulaw
fax-relay ecm disable
fax-relay sg3-to-g3
fax rate 14400
fax protocol pass-through g711ulaw
no vad
06-28-2022 06:45 PM
06-29-2022 11:58 AM - edited 06-29-2022 12:24 PM
All, I figured out my solution on my own. The original post was to be a two part question. It turns out my diversion header was working just as it was supposed to, using the called destination profile, an owned DID, as the diversion header (that which is supported by my provider). This was just a brain cramp on my part.
Part two of the question was going to be, how can I send the original CALLED party number for a single remote destination/SNR profile, but leave the CALLING party for all other SNR profiles. This I can and did accomplish using a calling party transformation pattern to mask the calling party with the original called party DN.
Thank you so much for your replies. I think in checking what you, @Daniel Bosch, posted made me realize my gateway/trunk configuration is solid for most normal scenarios and I needed to think differently.
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