cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
1477
Views
40
Helpful
18
Replies
Highlighted
Participant

CUCM 8.6 > SIP Trunk > CUBE > SIP Trunk - Ringing / Connected Party Display

Hi Support Community

When we place calls from an IP phone to a H323 ISDN gateway we globalise the number in translation patterns so the display on the calling phone is the E164 number so for example +442071234567. We want this to display even when the call is ringing / connected so we use the command no supplementary-service h225-notify cid-update on the H323 gateway otherwise the alerting display is updated with the number from the matched dial peer when ringing and connected.

 

When we place calls from an IP phone to a SIP CUBE the number is again globalised to E164 in translation patterns however as soon as we hear ringback the display on the calling IP phone displays "private". Can somebody please advise if there is an equivalent in SIP to the command no supplementary-service h225-notify cid-update.
 

These are the debug CCSIP messages from the CUBE :

 

000267: Oct  2 10:38:35.506 UTC: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+44XXXXXX0875@172.23.255.99:5060 SIP/2.0
Via: SIP/2.0/TCP 172.20.44.104:5060;branch=z9hG4bK3e5ecc3bcebb92
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=25280178~17337b8f-a50d-45a4-8f3a-f81dd5cc611b-41234378
To: <sip:+44XXXXXX0875@172.23.255.99>
Date: Fri, 02 Oct 2015 09:38:35 GMT
Call-ID: 58b46500-60e1509b-30ec6d-682c14ac@172.20.44.104
Supported: timer,resource-priority,replaces
Min-SE:  1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Cisco-Guid: 1488217344-0000065536-0000054240-1747719340
Session-Expires:  1800
P-Asserted-Identity: "CR Test MAN - 3022852" <sip:+44XXXXXX2852@172.20.44.104>
Privacy: id
Remote-Party-ID: "CR Test MAN - 3022852" <sip:+44XXXXXX2852@172.20.44.104>;party=calling;screen=yes;privacy=uri
Contact: <sip:172.20.44.104:5060;transport=tcp>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 219

v=0
o=CiscoSystemsCCM-SIP 25280178 1 IN IP4 172.20.44.104
s=SIP Call
c=IN IP4 172.20.255.249
t=0 0
m=audio 30088 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

000268: Oct  2 10:38:35.522 UTC: //698/58B465000000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:44XXXXXX0875@192.168.200.30:5060 SIP/2.0
Via: SIP/2.0/UDP 172.23.255.99:5060;branch=z9hG4bK54613BD
Remote-Party-ID: "CR Test MAN - 3022852" <sip:+44XXXXXX2852@172.23.255.99>;party=calling;screen=yes;privacy=full
From: "anonymous" <sip:anonymous@172.23.255.99>;tag=2E995B0-BF7
To: <sip:44XXXXXX0875@192.168.200.30>
Date: Fri, 02 Oct 2015 09:38:35 GMT
Call-ID: 2FD1ADCE-682011E5-8902E25E-44D397BD@172.23.255.99
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 1488217344-0000065536-0000054240-1747719340
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1443778715
Contact: <sip:anonymous@172.23.255.99:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires:  1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 250

v=0
o=CiscoSystemsSIP-GW-UserAgent 1367 2609 IN IP4 172.23.255.99
s=SIP Call
c=IN IP4 172.23.255.99
t=0 0
m=audio 17778 RTP/AVP 8 101
c=IN IP4 172.23.255.99
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

000269: Oct  2 10:38:35.522 UTC: //697/58B465000000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 172.20.44.104:5060;branch=z9hG4bK3e5ecc3bcebb92
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=25280178~17337b8f-a50d-45a4-8f3a-f81dd5cc611b-41234378
To: <sip:+44XXXXXX0875@172.23.255.99>
Date: Fri, 02 Oct 2015 09:38:35 GMT
Call-ID: 58b46500-60e1509b-30ec6d-682c14ac@172.20.44.104
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.4.3.M3
Content-Length: 0


000270: Oct  2 10:38:35.534 UTC: //698/58B465000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.23.255.99:5060;branch=z9hG4bK54613BD
From: "anonymous" <sip:anonymous@172.23.255.99>;tag=2E995B0-BF7
To: <sip:44XXXXXX0875@192.168.200.30>;tag=gK0291ecd6
Call-ID: 2FD1ADCE-682011E5-8902E25E-44D397BD@172.23.255.99
CSeq: 101 INVITE
Timestamp: 1443778715
Content-Length: 0

 

 

000275: Oct  2 10:38:38.422 UTC: //698/58B465000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 172.23.255.99:5060;branch=z9hG4bK54613BD
From: "anonymous" <sip:anonymous@172.23.255.99>;tag=2E995B0-BF7
To: <sip:44XXXXXX0875@192.168.200.30>;tag=gK0291ecd6
Call-ID: 2FD1ADCE-682011E5-8902E25E-44D397BD@172.23.255.99
CSeq: 101 INVITE
Contact: <sip:44XXXXXX0875@192.168.200.29:5060>
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Require: 100rel
RSeq: 26192
Content-Length:  235
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 9594 10406 IN IP4 192.168.200.29
s=SIP Media Capabilities
c=IN IP4 192.168.200.4
t=0 0
m=audio 21708 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20

000276: Oct  2 10:38:38.426 UTC: //698/58B465000000/SIP/Msg/ccsipDisplayMsg:
Sent:
PRACK sip:44XXXXXX0875@192.168.200.29:5060 SIP/2.0
Via: SIP/2.0/UDP 172.23.255.99:5060;branch=z9hG4bK54824BE
From: "anonymous" <sip:anonymous@172.23.255.99>;tag=2E995B0-BF7
To: <sip:44XXXXXX0875@192.168.200.30>;tag=gK0291ecd6
Date: Fri, 02 Oct 2015 09:38:35 GMT
Call-ID: 2FD1ADCE-682011E5-8902E25E-44D397BD@172.23.255.99
CSeq: 102 PRACK
RAck: 26192 101 INVITE
Allow-Events: telephone-event
Max-Forwards: 70
Content-Length: 0


000277: Oct  2 10:38:38.430 UTC: //697/58B465000000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP 172.20.44.104:5060;branch=z9hG4bK3e5ecc3bcebb92
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=25280178~17337b8f-a50d-45a4-8f3a-f81dd5cc611b-41234378
To: <sip:+44XXXXXX0875@172.23.255.99>;tag=2E9A10C-CB9
Date: Fri, 02 Oct 2015 09:38:35 GMT
Call-ID: 58b46500-60e1509b-30ec6d-682c14ac@172.20.44.104
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:44XXXXXX0875@172.23.255.99>;party=called;screen=yes;privacy=full
Contact: <sip:+44XXXXXX0875@172.23.255.99:5060;transport=tcp>
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.4.3.M3
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 250

v=0
o=CiscoSystemsSIP-GW-UserAgent 7824 1232 IN IP4 172.23.255.99
s=SIP Call
c=IN IP4 172.23.255.99
t=0 0
m=audio 17776 RTP/AVP 8 101
c=IN IP4 172.23.255.99
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

000278: Oct  2 10:38:38.442 UTC: //698/58B465000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.23.255.99:5060;branch=z9hG4bK54824BE
From: "anonymous" <sip:anonymous@172.23.255.99>;tag=2E995B0-BF7
To: <sip:44XXXXXX0875@192.168.200.30>;tag=gK0291ecd6
Call-ID: 2FD1ADCE-682011E5-8902E25E-44D397BD@172.23.255.99
CSeq: 102 PRACK
Content-Length: 0


000279: Oct  2 10:38:38.922 UTC: //698/58B465000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.23.255.99:5060;branch=z9hG4bK54613BD
From: "anonymous" <sip:anonymous@172.23.255.99>;tag=2E995B0-BF7
To: <sip:44XXXXXX0875@192.168.200.30>;tag=gK0291ecd6
Call-ID: 2FD1ADCE-682011E5-8902E25E-44D397BD@172.23.255.99
CSeq: 101 INVITE
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay,  multipart/mixed
Contact: <sip:44XXXXXX0875@192.168.200.29:5060>
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Require: timer
Supported: timer
Session-Expires: 1800;refresher=uac
Content-Length:  235
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 9594 10406 IN IP4 192.168.200.29
s=SIP Media Capabilities
c=IN IP4 192.168.200.4
t=0 0
m=audio 21708 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20

000280: Oct  2 10:38:38.926 UTC: //697/58B465000000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 172.20.44.104:5060;branch=z9hG4bK3e5ecc3bcebb92
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=25280178~17337b8f-a50d-45a4-8f3a-f81dd5cc611b-41234378
To: <sip:+44XXXXXX0875@172.23.255.99>;tag=2E9A10C-CB9
Date: Fri, 02 Oct 2015 09:38:35 GMT
Call-ID: 58b46500-60e1509b-30ec6d-682c14ac@172.20.44.104
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:44XXXXXX0875@172.23.255.99>;party=called;screen=no;privacy=off
Contact: <sip:44XXXXXX0875@172.23.255.99:5060;transport=tcp>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.4.3.M3
Session-Expires:  1800;refresher=uac
Require: timer
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 250

v=0
o=CiscoSystemsSIP-GW-UserAgent 7824 1232 IN IP4 172.23.255.99
s=SIP Call
c=IN IP4 172.23.255.99
t=0 0
m=audio 17776 RTP/AVP 8 101
c=IN IP4 172.23.255.99
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

000281: Oct  2 10:38:38.926 UTC: //698/58B465000000/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:44XXXXXX0875@192.168.200.29:5060 SIP/2.0
Via: SIP/2.0/UDP 172.23.255.99:5060;branch=z9hG4bK549768
From: "anonymous" <sip:anonymous@172.23.255.99>;tag=2E995B0-BF7
To: <sip:44XXXXXX0875@192.168.200.30>;tag=gK0291ecd6
Date: Fri, 02 Oct 2015 09:38:35 GMT
Call-ID: 2FD1ADCE-682011E5-8902E25E-44D397BD@172.23.255.99
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0


000282: Oct  2 10:38:38.934 UTC: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:44XXXXXX0875@172.23.255.99:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 172.20.44.104:5060;branch=z9hG4bK3e5ece183b5108
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=25280178~17337b8f-a50d-45a4-8f3a-f81dd5cc611b-41234378
To: <sip:+44XXXXXX0875@172.23.255.99>;tag=2E9A10C-CB9
Date: Fri, 02 Oct 2015 09:38:35 GMT
Call-ID: 58b46500-60e1509b-30ec6d-682c14ac@172.20.44.104
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence, kpml
Privacy: id
Content-Length: 0


000283: Oct  2 10:38:45.426 UTC: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
BYE sip:44XXXXXX0875@172.23.255.99:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 172.20.44.104:5060;branch=z9hG4bK3e5ed866258a9
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=25280178~17337b8f-a50d-45a4-8f3a-f81dd5cc611b-41234378
To: <sip:+44XXXXXX0875@172.23.255.99>;tag=2E9A10C-CB9
Date: Fri, 02 Oct 2015 09:38:35 GMT
Call-ID: 58b46500-60e1509b-30ec6d-682c14ac@172.20.44.104
User-Agent: Cisco-CUCM8.6
Max-Forwards: 70
Privacy: id
P-Asserted-Identity: "CR Test MAN - 3022852" <sip:+44XXXXXX2852@172.20.44.104>
CSeq: 102 BYE
Reason: Q.850;cause=16
Content-Length: 0


000284: Oct  2 10:38:45.430 UTC: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 172.20.44.104:5060;branch=z9hG4bK3e5ed866258a9
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=25280178~17337b8f-a50d-45a4-8f3a-f81dd5cc611b-41234378
To: <sip:+44XXXXXX0875@172.23.255.99>;tag=2E9A10C-CB9
Date: Fri, 02 Oct 2015 09:38:45 GMT
Call-ID: 58b46500-60e1509b-30ec6d-682c14ac@172.20.44.104
Server: Cisco-SIPGateway/IOS-15.4.3.M3
CSeq: 102 BYE
Reason: Q.850;cause=16
P-RTP-Stat: PS=351,OS=56160,PR=342,OR=54720,PL=0,JI=0,LA=0,DU=6
Content-Length: 0


000285: Oct  2 10:38:45.434 UTC: //698/58B465000000/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:44XXXXXX0875@192.168.200.29:5060 SIP/2.0
Via: SIP/2.0/UDP 172.23.255.99:5060;branch=z9hG4bK54A13C3
From: "anonymous" <sip:anonymous@172.23.255.99>;tag=2E995B0-BF7
To: <sip:44XXXXXX0875@192.168.200.30>;tag=gK0291ecd6
Date: Fri, 02 Oct 2015 09:38:35 GMT
Call-ID: 2FD1ADCE-682011E5-8902E25E-44D397BD@172.23.255.99
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M3
Max-Forwards: 70
Timestamp: 1443778725
CSeq: 103 BYE
Reason: Q.850;cause=16
P-RTP-Stat: PS=342,OS=54720,PR=480,OR=76800,PL=0,JI=0,LA=0,DU=6
Content-Length: 0


000286: Oct  2 10:38:45.454 UTC: //698/58B465000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.23.255.99:5060;branch=z9hG4bK54A13C3
From: "anonymous" <sip:anonymous@172.23.255.99>;tag=2E995B0-BF7
To: <sip:44XXXXXX0875@192.168.200.30>;tag=gK0291ecd6
Call-ID: 2FD1ADCE-682011E5-8902E25E-44D397BD@172.23.255.99
CSeq: 103 BYE
Content-Length: 0

 

 

Carl Ratcliffe

Preston-Lancashire-England

2 ACCEPTED SOLUTIONS

Accepted Solutions
Highlighted

Carl,

Understanding why you are getting the private in ringing state will lead us to solve this much more efficiently.

If we look at the 183 Session Progress sent to CUCM..

+++ Here see that called party privay=full (this means Private)

Sent:
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP 172.20.44.104:5060;branch=z9hG4bK3e5ecc3bcebb92
-
Remote-Party-ID: <sip:44XXXXXX0875@172.23.255.99>;party=called;screen=yes;privacy=full

Now that we know this, I would take a different approach to resolving this rather than disabling remote-party id altogether..

Here is my proposed solution..

voice class sip-profiles 3
  response 183 sip-header Remote-Party-ID modify "<sip:(44XXXXXX0875)@172.23.255.99>" "<sip:+\1@172.23.255.99>"

Then you need to apply the sip profile to the inbound leg od the call..ie cucm to cube

dial-peer voice xxx voip
voice-class sip profiles 3

Now when the call is in the ringing state, the full display will be the +44....Which was the originally called number.

 

 

Please rate all useful posts

View solution in original post

Highlighted

Carl,

Yes you can use the following wild card to catch all numbers beginning with 44

voice class sip-profiles 3
  response 183 sip-header Remote-Party-ID modify "<sip:44(.*)@172.23.255.99>" "<sip:+44\1@172.23.255.99>"

Please rate all useful posts

View solution in original post

18 REPLIES 18
Highlighted
Cisco Employee

Hi Carl,

You can try "no update caller-id" under voice sevice voip > sip ,  and see if it helps.

 

Manish

Highlighted

Thanks Manish I will give that a try. I also read that you can use the following

 

sip-ua

  no remote-party-id

 

Carl Ratcliffe

Preston-Lancashire-England

Highlighted

Hi Carl,

Seems this option should work. Doing so, CUBE will not include remote-party-id in SIP response response and hence global translated number should be displayed on phone LCD.

Thanks 

Highlighted

Thanks, I will try both options in a change window.

 

Carl Ratcliffe

Preston-Lancashire-England

Highlighted

Carl,

Understanding why you are getting the private in ringing state will lead us to solve this much more efficiently.

If we look at the 183 Session Progress sent to CUCM..

+++ Here see that called party privay=full (this means Private)

Sent:
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP 172.20.44.104:5060;branch=z9hG4bK3e5ecc3bcebb92
-
Remote-Party-ID: <sip:44XXXXXX0875@172.23.255.99>;party=called;screen=yes;privacy=full

Now that we know this, I would take a different approach to resolving this rather than disabling remote-party id altogether..

Here is my proposed solution..

voice class sip-profiles 3
  response 183 sip-header Remote-Party-ID modify "<sip:(44XXXXXX0875)@172.23.255.99>" "<sip:+\1@172.23.255.99>"

Then you need to apply the sip profile to the inbound leg od the call..ie cucm to cube

dial-peer voice xxx voip
voice-class sip profiles 3

Now when the call is in the ringing state, the full display will be the +44....Which was the originally called number.

 

 

Please rate all useful posts

View solution in original post

Highlighted

Efficient way to fix it Ayodeji (+5). I'm excited to see there are always more than one option exist to fix the same issue.

Thanks

Highlighted

Hi Ayodeji

 

Thanks for your response. Just to be clear, the example you gave includes a specific called number - "<sip:(44XXXXXX0875)@172.23.255.99>" , what is the wildcard to be used in sip profiles so that this applies to any called number ?

 

I will need to submit a change control then I can test and feedback the results.

 

Carl Ratcliffe

Preston-Lancashire-England

 

 

Highlighted

Carl,

Yes you can use the following wild card to catch all numbers beginning with 44

voice class sip-profiles 3
  response 183 sip-header Remote-Party-ID modify "<sip:44(.*)@172.23.255.99>" "<sip:+44\1@172.23.255.99>"

Please rate all useful posts

View solution in original post

Highlighted

Excellent, thanks.

 

One last question, the SIP message is from the CUBE and although it says sent this is still CUCM sending to CUBE as opposed to the CUBE sending to CUCM which is why you apply it on the inbound dial peer ?

 

I have read you sip trace post several times by the way and its a good read for anyone - https://supportforums.cisco.com/document/113271/understanding-sip-traces

 

 

 

Sent:
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP 172.20.44.104:5060;branch=z9hG4bK3e5ecc3bcebb92
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=25280178~17337b8f-a50d-45a4-8f3a-f81dd5cc611b-41234378
To: <sip:+44XXXXXX0875@172.23.255.99>;tag=2E9A10C-CB9
Date: Fri, 02 Oct 2015 09:38:35 GMT
Call-ID: 58b46500-60e1509b-30ec6d-682c14ac@172.20.44.104
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:44XXXXXX0875@172.23.255.99>;party=called;screen=yes;privacy=full
Contact: <sip:+44XXXXXX0875@172.23.255.99:5060;transport=tcp>
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.4.3.M3
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 250

 

Carl Ratcliffe

Preston-Lancashire-England

Highlighted

Carl,

No it is "Sent"..so it is CUBE sending it to cucm. But this is a provisional response hence we can only use the inbound dial-peer that the original invite arrived on. So if we need to do any manipulation to the call it has to happen on that inbound dial-peer as there is no other dial-peer that will be matched for a response..

Thank you for the compliment on the documentation. It has been one of my best work on the forums. Almost 75,000 views!!!.

Please rate all useful posts
Highlighted

Hi Ayodeji

I'm having the same problem and used the sip profile to add the + back on from the cube.  This works for some nubmers when the call is ringing, and connected, but if the call is goes to voicemail the + disappears again.  For other numbers the + is not re-appearing at all.  Is there somthing other than the remote-party-id that can be modified?  My goal of course is once the called number is globalized the user sees the + through end of the call.

thanks!

Mark

Highlighted

I'm getting closer.  I'm in the US, so I am sending all Local and National calls out 1[2-9]XX[2-9]XXXXXX.  International calls us 011  So I modified my profile to look like this:

voice class sip-profiles 1
 response 183 sip-header Remote-Party-ID modify "<sip:011(.*)@" "<sip:+\1@"
 response 183 sip-header Remote-Party-ID modify "<sip:(.*)@" "<sip:+\1@"
 response 200 sip-header Remote-Party-ID modify "<sip:011(.*)@" "<sip:+\1@"
 response 200 sip-header Remote-Party-ID modify "<sip:(.*)@" "<sip:+\1@"

This is applied to the dial-peer receiving the calls from CUCM and it works fine for national calls.  However, if I dial the Kansai Airport in Japan the number displays as ++81724552500.  So unlike translation rules and access lists, it appears the sip profiles to not stop processing when there is a match. So as far as I can see the solution is to do this:

voice class sip-profiles 1
 response 183 sip-header Remote-Party-ID modify "<sip:011(.*)@" "<sip:+\1@"
 response 183 sip-header Remote-Party-ID modify "<sip:(1.*)@" "<sip:+\1@"
 response 200 sip-header Remote-Party-ID modify "<sip:011(.*)@" "<sip:+\1@"
 response 200 sip-header Remote-Party-ID modify "<sip:(1.*)@" "<sip:+\1@"

Is this the best answer?

Do I need both 183 and 200? (it appeared not all calls were updating with only the 183)

Highlighted

Yes you may need it for 200 OK too. The idea is that you test each phase of the call and then apply the rules as they fit what you want. 

Don't forget to rate helpful posts 

Please rate all useful posts
Highlighted

I tried without the 183 and it failed. So it looks like then the best option for the US would look something like this:

 
voice class sip-profiles 1
 response 183 sip-header Remote-Party-ID modify "<sip:011(.*)@" "<sip:+\1@"
 response 183 sip-header Remote-Party-ID modify "<sip:1([2-9]..[2-9]......)@" "<sip:+1\1@"
 response 183 sip-header Remote-Party-ID modify "<sip:([2-9]..[2-9]......)@" "<sip:+1\1@"
 response 200 sip-header Remote-Party-ID modify "<sip:011(.*)@" "<sip:+\1@"
 response 200 sip-header Remote-Party-ID modify "<sip:1([2-9]..[2-9]......)@" "<sip:+1\1@"
 response 200 sip-header Remote-Party-ID modify "<sip:([2-9]..[2-9]......)@" "<sip:+1\1@"

This is applied to the dial peer that is incoming from CUCM.  The profile could be modified per region/country to match local dialing patterns.  Thanks for the tips!

Content for Community-Ad