cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1444
Views
5
Helpful
2
Replies

Cisco CUBE stripping SIP header information we need to pass through

Hi All the SIP Manipulation Guru's I need some help here.

We have a call coming from Genesys Agent --> AudioCodes SBC --> Cisco CUBE -- ITSP --> Genesys Cloud

We need the uui information to be retained in the SIP header but the CUBE seems to be stripping it off.

 

Incoming message from Audiocodes SBC to Cisco CUBE "field we want to retain = X-User-To-User: Test User ;encoding=ascii"

Received:
INVITE sip:40123456789@example.com SIP/2.0
Via: SIP/2.0/TCP 1.1.1.1:5060;alias;branch=z9hG4bKac472207109
Max-Forwards: 68
From: "anonymous" <sip:anonymous@anonymous.invalid>;tag=1c523572471
To: <sip:40123456789@example.com>
Call-ID: 1108047860175202212564@1.1.1.1
CSeq: 1 INVITE
Contact: <sip:52980@1.1.1.1:5060;transport=tcp>
Supported: uui,100rel,timer,sdp-anat
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, UPDATE
Session-Expires: 1800;refresher=uac
Min-SE: 90
User-Agent: Audiocodes.sbc.com/v.7.20A.204.128
Content-Type: application/sdp
Content-Length: 236
X-Genesys-CallInfo: routed
X-User-To-User: Test User ;encoding=ascii
X-Genesys-CallUUID: G8LDD31G6D4EF0R4Q1QUGFIMK8002U7C
X-ISCC-CofId: location=ccaas_sip_t_server_switch;cofid=17103091

v=0
o=- 1735349391 643427642 IN IP4 1.1.1.1
s=-
c=IN IP4 1.1.1.1
t=0 0
m=audio 12440 RTP/AVP 8 96
c=IN IP4 1.1.1.1
a=sendrecv
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15,16

Outgoing INVITE from CUBE to ITSP all the header information below the Content-Length has been stripped.

Sent:
INVITE sip:+1234567890@2.2.2.2:5060 SIP/2.0
Via: SIP/2.0/TCP 3.2.3.2:5060;branch=z9hG4bK239DD0C270
From: "anonymous" <sip:anonymous@2.2.2.2>;tag=137E7BE2-1D37
To: <sip:+1234567890@2.2.2.2>
Date: Tue, 17 May 2022 00:56:06 GMT
Call-ID: F750FD0A-D4B211EC-86F989AB-3FB297A8@3.2.3.2
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 4149209975-3568439788-2264107435-1068668840
User-Agent: Cisco-SIPGateway/IOS-16.3.2
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1652748966
Contact: <sip:anonymous@3.2.3.2:5060;transport=tcp>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 67
Session-ID: cb71378d3a5959188f0114db483b5b68;remote=00000000000000000000000000000000
Session-Expires: 1800;refresher=uac
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 277

I have tried the following sip profile on the outbound dial-peer, not sure if I should have it on the inbound dial-peer?
I need it for 1 number only which is splitting off to a different ITSP than the rest of the calls.


voice class sip-profiles 800
request INVITE peer-header sip X-User-To-User copy "X-User-To-User: (X-.*)" u01
request INVITE sip-header X-User-To-User modify "X-User-To-User: " "X-User-To-User: \u01\2"

dial-peer voice 800
voice-class sip profiles 800

My inbound dial-peer matches on "incoming uri via AudiocodeSBC"
I have tried adding a voip dial-peer for inbound matching on both "incoming uri via AudiocodeSBC" and "destination uri-via PATTERN" but it keeps on matching only the original dial-peer that only matches on "incoming uri via AudiocodeSBC"
Is there a why I can with the current inbound matching dial-peer split off just the 1 destination pattern and then do the SIP manipulation on that inbound dial-peer before passing it to the outbound dial-peer retaining or keeping the header information we need?

I have also tried adding on the outbound dial-peer "voice-class sip pass-thru headers 800":
!
voice class sip-profiles 800
request INVITE peer-header sip X-User-To-User copy "X-User-To-User: (X-.*)" u01
request INVITE sip-header X-User-To-User modify "X-User-To-User: " "X-User-To-User: \u01\2"
!
!
voice class sip-hdr-passthrulist 800
passthru-hdr X-User-To-User
passthru-hdr-unsupp

!
dial-peer voice 800 voip
description Outbound Calls TO GenesysCloud
translation-profile outgoing StripLeadingDigitOut
destination-pattern 1.T
media monitoring
session protocol sipv2
session target ipv4:2.2.2.2
session transport tcp
voice-class codec 1 offer-all
voice-class sip profiles 800
voice-class sip tenant 999
voice-class sip options-keepalive profile 30
voice-class sip pass-thru headers 800
voice-class sip bind control source-interface GigabitEthernet0/0/2
voice-class sip bind media source-interface GigabitEthernet0/0/2
dtmf-relay rtp-nte
no vad

So I guess my question is, is there a way I can copy the peer-header information from the inbound dial-peer for the spesific call and add it to the outbound leg via the outbound dial-peer?
Do I do this manipulation on the inbound dial-peer or outbound dial-peer?
Or is there and easier way to pass the following information via the CUBE and not stripping it?
X-Genesys-CallInfo: routed
X-User-To-User: Test User ;encoding=ascii
X-Genesys-CallUUID: G8LDD31G6D4EF0R4Q1QUGFIMK8002U7C
X-ISCC-CofId: location=ccaas_sip_t_server_switch;cofid=17103091

 

I have tried the SIP-Profile Test Tool (cisco.com) but it will not copy the fields from the inbound message to the message that needs to be manipulated.

 

Any help or advice would be appreciated.

Best Regards
1 Accepted Solution

Accepted Solutions

b.winter
VIP
VIP

Hi,

 

I have tried adding a voip dial-peer for inbound matching on both "incoming uri via AudiocodeSBC" and "destination uri-via PATTERN" but it keeps on matching only the original dial-peer that only matches on "incoming uri via AudiocodeSBC"

=> This is normal, since the priority of URI matching is higher, then a number matching. Check out the documentation about that.

 

I have also tried adding on the outbound dial-peer "voice-class sip pass-thru headers 800"

=> Again, it will not work. You need to assign it to the inbound dial-peer. Again, check out the documentation. There is like a complete "book" on the cisco website, explaining the functionalities and all the commands in detail and how to apply them.

 

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_pass_unsupported.html

 

You could also enable the list at global level:

voice service voip
 sip
  pass-thru headers list 800

 

If you wanna copy headers values from the inbound to the outbound dial-peer, check out the sip-copy list feature.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_copy_sip_headers.html

View solution in original post

2 Replies 2

b.winter
VIP
VIP

Hi,

 

I have tried adding a voip dial-peer for inbound matching on both "incoming uri via AudiocodeSBC" and "destination uri-via PATTERN" but it keeps on matching only the original dial-peer that only matches on "incoming uri via AudiocodeSBC"

=> This is normal, since the priority of URI matching is higher, then a number matching. Check out the documentation about that.

 

I have also tried adding on the outbound dial-peer "voice-class sip pass-thru headers 800"

=> Again, it will not work. You need to assign it to the inbound dial-peer. Again, check out the documentation. There is like a complete "book" on the cisco website, explaining the functionalities and all the commands in detail and how to apply them.

 

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_pass_unsupported.html

 

You could also enable the list at global level:

voice service voip
 sip
  pass-thru headers list 800

 

If you wanna copy headers values from the inbound to the outbound dial-peer, check out the sip-copy list feature.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_copy_sip_headers.html

I have enabled the pass-thru headers list on the inbound dial-peer stating all headers I want to pass thru as well as passthru-hdr-unsupp and it is passing the value to ITSP now.

Thanks for the answer got it going more or less the same time you answered but well done, and yes I am aware of this=> This is normal, since the priority of URI matching is higher, then a number matching. Check out the documentation about that, just tried to get around it but then only after running debug ccsip all I saw it is all unsupported headers which lead me not to affect any other tenant just to enabled it for the specific tenant on the inbound dial-peer.

Best Regards