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/ //
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
dial-peer voice YYYY voip
translation-profile incoming 1
translation-profile outgoing 2
destination pattern 200.
voice service voip
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?
Can you attach a debug ccsip message of a transfer call that did not work/show the correct caller id
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
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++++
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
The question is are you dialling 7002 for xfer or 27002?
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
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..
INVITE sip:firstname.lastname@example.org:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.2.254:5060;branch=z9hG4bK212675
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.0.2.254:5060;branch=z9hG4bK212675
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/
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.
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:email@example.com>;tag=1919715C-1AC5 To: <sip:firstname.lastname@example.org> 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)