03-25-2014 02:20 AM - edited 03-16-2019 10:14 PM
Hi,
We are having difficulties to configure properly the CUBE for digit translation in SIP-only world:
Our internal numbering plan is 4 digits and we must add/remove a prefix to our internal phone numbers when calling/being called:
Prefix is 200. The phone number is 7001
- When we call XXXX, the FROM field should be 2007001 after translation.
- When XXX is calling us, he dials 2007001 but the TO field should be 7001 after translation.
- Same translation rules to be applied to other fields such as REFER, CONTACT, etc. for consistency
The translation rules are working well for "normal" calls but we don't succeed to make it work for call transfer: Some cases are working with correct caller phone number display on the callee side, others are not working (either call refer is rejected or is accepted but wrong calling phone number is presented).
Here is an extract of our configuration for translation rules:
voice translation-rule 1
rule 1 /7.../ /200&/
voice translation-rule 2
rule 1 /^200/ //
voice translation-profile
translate calling 1
translate redirect-target 1
translate redirect-called 1
translate callback-number 1
voice translation-profile 2
translate called 2
translate redirect-target 2
translate redirect-called 2
translate callback-number 2
dial-peer voice XXX voip
translation-profile incoming 2
translation-profile outgoing 1
destination-pattern XXX
session-target X.X.X.X
dial-peer voice YYYY voip
translation-profile incoming 1
translation-profile outgoing 2
destination pattern 200.
session-target Y.Y.Y.Y
voice service voip
sip
referto-passing
We don't see what is wrong and what to to do to have it working. We don't even know if all commands in the translation profiles (redirect, callback) added to handle call transfer are needed...
Anybody to give us an hint?
Thanks :-)
03-25-2014 04:00 AM
Can you attach a debug ccsip message of a transfer call that did not work/show the correct caller id
03-25-2014 08:12 AM
Here is an example of a failed transfer.
The CUBE acts as an SBC and has IP address 172.16.1.200 on the local side, and IP address 10.0.0.254 on the external side. The local SIP server has IP address 172.16.1.1.
The call is made from local user 7001 to external user 9493311001001. The goal is to transfer this call from local user 7001 to local user 7002.
I send 2 debug traces:
- one where the transfer succeeded but the phone number is not translated (7002 presented to external user instead of 2007002): ccsip_transfer_OK_number_NOK.txt
- one where the transfer fails: ccsip_transfer_NOK.txt
03-25-2014 09:15 AM
I have looked at the logs and the reason why the transfer is failing is because the "xfered to" number is wrong..
++Here is a working xfer++++
Refer-To: sip:27002@10.0.2.254?Replaces=4cdec8da49a6abcf%4010.0.2.254%3Bto-tag%3Dd51d1d8e44%3Bfrom-tag%3Dd4a88c44
Referred-By: <sip:7001@10.0.2.254>
The Refer-To is the number to be xfered to. In this case the number is 27002.
For the failed xfer, the Refered-To number is 7002.
xfer not working
Refer-To: sip:7002@172.16.1.1:5060?Replaces=4be9c34149a60bd6%40172.16.3.4%3Bto-tag%3Dbce4cc7d11%3Bfrom-tag%3D6f747ebf11
Referred-By: <sip:7001@10.0.2.254>
The question is are you dialling 7002 for xfer or 27002?
03-25-2014 10:15 AM
Thanks for your quick answer.
The scenario for both logs is the following: The local user 7001 first calls the external user 9493311001001, then put it in hold and calls the internal user 7002 (dialling 7002). Finally 7001 is transfering internal user 7002 (dialling 7002) to external user 9493311001001.
We don't understand why in one case, the Cisco is translating the 7002 phone number in the refer-to field while in the other case it doesn't, since we are strictly doing the same actions.
Moreover, in the working xfer case, we don't understand why the Cisco is not translating the contact header field in the 200 OK message (this is correctly translated in previous INVITE messages for example). At least this explains why the external user displays the wrong phone number...
Some complementary information: We are using Cisco 3925 routers running iOS 15.2.4M2
03-25-2014 10:19 AM
Please send your full sh run.
The CLI is the same on both calls. The CUBE sends the INVITE with the correct CLI, but the ITSP changes it when it sends the 180 ringing..look at the remote party id..It has changed to the called number which is strange to me..
Sent:
INVITE sip:9493311001001@10.0.0.254:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.2.254:5060;branch=z9hG4bK212675
Remote-Party-ID: <sip:27001@10.0.2.254>;party=calling;screen=no;privacy=off
From: <sip:27001@10.0.2.254>;tag=FCDB0-AE7
Contact: <sip:27001@10.0.2.254:5060>
Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.0.2.254:5060;branch=z9hG4bK212675
From: <sip:27001@10.0.2.254>;tag=FCDB0-AE7
To: <sip:9493311001001@10.0.0.254>;tag=14DE928C-2088
Remote-Party-ID: <sip:9493311001001@10.0.0.254>;party=called;screen=no;privacy=off
Contact: <sip:9493311001001@10.0.0.254:5060>
03-25-2014 10:59 AM
03-26-2014 02:20 AM
Ok..
Lets try this..Chnage the voice translation rule..
Then test again. You will need to ask the provider why they are changing the CLI to the called number. It should be the calling number. This is their doing.
voice translation-rule 1 rule 1 /\(7...\)/ /2\1/
03-26-2014 05:47 AM
We changed it (and also removed the remote-party-ID field to improve privacy) but we still have the same seldom behaviour where the transfer working sometimes (with the contact header field not translated in the 200 OK message) or not working...
By the way, we are doing local tests today meaning that we are not interfacing a real ITSP but another SBC with telephones behind. This other SBC we have configured doesn't have any translation rules applied, just to keep it simple. For info, xfers between the 2 SBCs are working well when we don't apply any translation rule (ie when the telephones have full telephone number with prefix configured). Since we are controlling the whole path, we can also do some modifications/logging on the other SBC if that helps...
I attach the new logs with both a working xfer and a non working one.
03-26-2014 06:34 AM
In the case of the non working xfer here, CUBE is sending
*Mar 26 10:38:17.915: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 481 Call Leg/Transaction Does Not Exist Via: SIP/2.0/UDP 10.0.0.254:5060;branch=z9hG4bK280D5E6 From: <sip:9493311001001@10.0.0.254>;tag=1919715C-1AC5 To: <sip:27002@10.0.2.254> Call-ID: C753E631-B40811E3-BF5DCD5C-8D3A06F3@10.0.0.254 Timestamp: 1395829954 CSeq: 101 INVITE Content-Length: 0
I will need to look at the logs in detail to find out whats going on. The other option is to disable refer all together and aloow CUBE to just use RE-INVITES for the transfer..You can try that.
I can also confirm that in this test the Refer-To number is correct (27002)
03-26-2014 06:59 AM
Having looked in detail at the logs, I can confirm that it is the SBC that is terminating the transfer due to no resource. It looks like that SBC cant handle REFER very well..disable it on your CUBE and let me know if it helps
Received:
NOTIFY sip:27001@10.0.2.254:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.254:5060;branch=z9hG4bK280BABC
From: <sip:9493311001001@10.0.0.254>;tag=19195160-25C
To: <sip:27001@10.0.2.254>;tag=4D1900-1042
Call-ID: 8EEC31A1-B40911E3-807BB289-81B7AA4F@10.0.2.254
CSeq: 102 NOTIFY
Max-Forwards: 70
Date: Wed, 26 Mar 2014 10:32:34 GMT
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M2
Event: refer
Subscription-State: terminated;reason=noresource
Contact: <sip:9493311001001@10.0.0.254:5060>
Content-Type: message/sipfrag
Content-Length: 33
You can disable REFER as follows:
conf t
voice service voip
no supplementary-service sip refer
03-30-2014 03:47 AM
Thanks, we will try this and come back asap with the status...
By the way, in a more general view, how should we configure digit translation in CUBE? Because you can do it in inbound dialpeers, outbound dialpeers, for incoming calls, for outgoing calls... Seems there are so many ways to do the same thing!
03-30-2014 09:41 AM
Yes, you can do it in several places. it all depends on what you want to manipulate. There is no one way to do it, you can do it in several ways
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