cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
890
Views
10
Helpful
4
Replies

Single number reach (SNR) - pass original calling party number

Stephanie Knoop
VIP Alumni
VIP Alumni

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.


Response Signature
1 Accepted Solution

Accepted Solutions

Stephanie Knoop
VIP Alumni
VIP Alumni

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.  

 


Response Signature

View solution in original post

4 Replies 4

Please share the output of debug ccsip message for a SNR call.



Response Signature


Daniel Bosch
Level 1
Level 1

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

Hi,

Have your tried to apply your SIP profile to 'request REINVITE' as well.

**** please remember to rate useful posts

Stephanie Knoop
VIP Alumni
VIP Alumni

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.  

 


Response Signature