Digit translation on SIP call transfer

[Thibault Groisil]

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

[Ayodeji Okanlawon]

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

[Thibault Groisil]

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

[Ayodeji Okanlawon]

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?

[Thibault Groisil]

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

[Ayodeji Okanlawon]

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>

[Thibault Groisil]

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.

[Ayodeji Okanlawon]

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/

[Thibault Groisil]

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.

[Ayodeji Okanlawon]

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)

[Ayodeji Okanlawon]

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

[Thibault Groisil]

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!

[Ayodeji Okanlawon]

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