Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Digit translation on SIP call transfer



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




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 :-)


  • IP Telephony
VIP Super Bronze

Can you attach a debug ccsip

Can you attach a debug ccsip message of a transfer call that did not work/show the correct caller id

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Here is an example of a

Here is an example of a failed transfer.

The CUBE acts as an SBC and has IP address on the local side, and IP address on the external side. The local SIP server has IP address

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


VIP Super Bronze

I have looked at the logs and

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@
Referred-By: <sip:7001@>

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@
Referred-By: <sip:7001@>

The question is are you dialling 7002 for xfer or 27002?


Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Thanks for your quick answer

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

VIP Super Bronze

Please send your full sh run

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:9493311001001@ SIP/2.0

Via: SIP/2.0/UDP;branch=z9hG4bK212675

Remote-Party-ID: <sip:27001@>;party=calling;screen=no;privacy=off

From: <sip:27001@>;tag=FCDB0-AE7

Contact: <sip:27001@>


SIP/2.0 180 Ringing

Via: SIP/2.0/UDP;branch=z9hG4bK212675

From: <sip:27001@>;tag=FCDB0-AE7

To: <sip:9493311001001@>;tag=14DE928C-2088

Remote-Party-ID: <sip:9493311001001@>;party=called;screen=no;privacy=off

Contact: <sip:9493311001001@>

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

We tought that the ITSP was

We tought that the ITSP was just putting his own information in return in the remote-party-ID and contact header fields...

I attach the full VoIP conf.

VIP Super Bronze




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/
Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

We changed it (and also

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.

VIP Super Bronze

In the case of the non

In the case of the non working xfer here, CUBE is sending

*Mar 26 10:38:17.915: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
SIP/2.0 481 Call Leg/Transaction Does Not Exist

Via: SIP/2.0/UDP;branch=z9hG4bK280D5E6

From: <sip:9493311001001@>;tag=1919715C-1AC5

To: <sip:27002@>

Call-ID: C753E631-B40811E3-BF5DCD5C-8D3A06F3@

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)

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
This widget could not be displayed.