Call transfer to outside getting disconnected

[Marko Rodic]

Hello,

We have a problem with transferring calls outside. This is how topology looks like:

PSTN - SIP - cisco router - SIP - CUCM 11.5

We need to transfer calls thats coming from PSTN, back through PSTN to outside number.

This is what is configured:

Lets say 020345678 is calling number, and they are calling 030123456.

Router is translating 030123456 to 2222, and sending it to CUCM

So, CUCM is receiving 020345678 as calling number and 2222 as called number.

Under translation, we are translating 2222 to 070123456, and sending it back to router. Under route pattering, we are also changing calling number to 2233.

So, router receive back info, that called number is 070123456 and calling number is 2233... And this is the moment when call is being disconnected. Im not sure whether router is finding exit leg dial-peer and attempting the call, or the call is disconnected in the moment when call is back on router

Additional info:

We did some tests and, if we try this with GSM gateway as exit leg from CUCM, same thing happens (we can even hear mobile phone starts ringing, and call is disconnected during first ring...).

If we transfer call to another phone on CUCM, it is transferred without problem.

If we call 2222 from local phone(lets say its 2244 phone), call is connected without problem. CUCM sends 2233 as calling number and 070123456 as called number, router translate 2233 to expected number, and connects the call.

One more thing. Same configuration was working on 8.5. It stopped working after we switched to 11.5.

I was doing some debugging of ccsip, and couldn't find significant error... Maybe I was trying to debug wrong thing, I don't know...

[julio.lee]

Hi Marko,

Could you provide with the call trace from RTMT from your test call? Also, does it disconnect after the destination picks up the call? 

[Marko Rodic]

Hello Julio,

It disconnects before destination pick ups a call

Since I can not send you whole trace call download, here is SIP messages part

[Ayodeji Okanlawon]

Is this number 7130 part of your DDI range? This is the CLI sent during the transfer..

P-Asserted-Identity: <sip:7130@172.31.0.4>

Remote-Party-ID: <sip:7130@172.31.0.4>;party=calling;screen=yes;privacy=off

[Marko Rodic]

No, but it is translated on outside dial-peer to DDI number. 

As I said, if you call from local, local number is also translated on same number(7130), and call is connected.

Again, same configuration has been working on 8.5 :) Same in sense, route patterns are same, CSS and partitions are same, translations are same... SIP trunk is as similar as it can be(there are more options on SIP profile on 11.5, but it is as close as it can be... calls through sip trunk are working, only call transfer is having an issue)

There is one more thing though. I don't know how significant it is. Calls through router goes slower. Not sure why as service parameters on both 8.5 and 11.5 version are same, and SIP trunk to PSTN hasn't been touched, its still slower... So there are differences even though configuration hasn't been changed.

[julio.lee]

Could you please attach the running configs on the voice gateway? 

[Marko Rodic]

Sorry, but there are infos that I'd rather keep private... Which part of configuration you are interested in, so I can get it?

[Ayodeji Okanlawon]

Gentleman,

If you want us to help, you have to provide the whole picture.

You need to provide all the logs in the call flow. You mentioned that the CLI is translated, but the logs I see doesnt show that. The call logs doesnt show the outbound leg to the PSTN, so we dont know what you are sending out..You can see that for yourself in the traces

When issues you need to look at them in the moment. Regardless of whether it was working before or not..

Right now, your logs shows that your translation on this call leg is not working.

Please provide the full gateway logs...

[Marko Rodic]

Sure thing. Just tell me how can I get these logs you are interested in?

If call goes from inside, and number 7445 is called, calling number is translated to 7130, called number is translated to 00216613566, and then its sent to the router. Same as here. Those are the logs that are requested and that I provided. Logs from CUCM. Rest from translation is on router.

So info that gets to router is calling number: 7130, called number: 00216613566, regardless from where you call.

However, if you call it from inside, call gets connected and its working.

If you call from outside, call gets disconnected.

I can not initiate the call from inside, as I'm not there. But I tried when I was in there. I can make test calls from outside and get logs from router and/or CUCM. I can't get debug ccsip all cause router will stop working. I can get debug ccsip messages, debug ccsip events, debug ccsip errors... Just tell me which logs you want to look at?

[Ayodeji Okanlawon]

All we need is the following..

1. CUCM logs if you can provide it

2. debug ccsip mess

3. sh run on gateway

4.debug voip ccapi inout

None of the debugs above will impact your gateway in any way

Please include all the numbers in the call..Calling, called, xlated etc

[Marko Rodic]

1. CUCM logs are in original post. 

2/4. Both debugs are in same file. First one, then other. I removed incoming called number and sip carrier number, as both are not important, and incoming called number is translated to 7445 as it should.

3. As I said above, no, I cant. However, since there are dial-peer 444 and dial-peer 20 involved, I will give you those. 

dial-peer voice 20 voip
description === OD CUBE KA TELEKOMU ===
translation-profile outgoing 2
preference 1
destination-pattern 0T
session protocol sipv2
session target sip-server
voice-class codec 1 offer-all
voice-class sip profiles 1
voice-class sip encap clear-channel standard
dtmf-relay rtp-nte h245-signal
fax-relay ecm disable
fax rate 9600
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
no vad

voice translation-profile 2
translate calling 2
translate called 5

voice translation-rule 5
rule 1 /^0\(.*\)/ /\1/

voice translation-rule 2
rule 1 /7\(...\)/ /XXX\1/

This is standard outgoing dial-peer which every phone is using when going outside, with its translation rules, and its working. All traslations, connectivity, everything is in order.

other dial-peer, created for testing

dial-peer voice 444 voip
translation-profile outgoing 44
destination-pattern XXX7212
session protocol sipv2
session target ipv4:172.31.0.4
voice-class codec 1 offer-all
voice-class sip profiles 1
dtmf-relay rtp-nte h245-signal
fax-relay ecm disable
fax rate 9600
no vad

voice translation-profile 44
translate called 43

voice translation-rule 43
rule 1 /^XXX7212/ /7445/

[Ayodeji Okanlawon]

The issue you are experiencing is related to a time out issue.

When CUBE receives the INVITE for the call..

++ INVITE received at 22:46:09 +++

Received:
INVITE sip:00216613566@172.31.0.3:5060 SIP/2.0
Via: SIP/2.0/TCP 172.31.0.4:5060;branch=z9hG4bK5936676397d6
From: <sip:7130@172.31.0.4>;tag=245249~d1d6c71b-3453-40fd-b15a-3e0db22af962-17758535
To: <sip:00216613566@172.31.0.3>
Date: Mon, 13 Nov 2017 22:46:09 GMT
Call-ID: 6f995400-a0a120b1-52d2-4001fac@172.31.0.4

++ It didn't send out  any INVITE and after 6sec, the first leg of the call was disconnected ++

TIGAR_VOICE_2921#
Nov 13 22:46:15: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
CANCEL sip:XXXXXXXXXXXX@10.1.9.6:5060 SIP/2.0
Via: SIP/2.0/UDP 10.136.0.132:5060;branch=z9hG4bKt8fueg3040qh9dhef4p0.1
CSeq: 466082497 CANCEL
To: "XXXXXXXXXXXX XXXXXXXXXXXX"<sip:XXXXXXXXXXXX@ims.telekomsrbija.com>;cscf
From: <sip:0606613564@10.8.255.9;user=phone>;tag=1699621558-1510613169537-
Call-ID: BW234609537131117-2064115579@10.137.24.4
Max-Forwards: 28
Content-Length: 0

++ The outbound leg was matched to dial-peer 20 ++

So you need to investigate why CUBE is not originating outbound INVITE after matching dial-peer

You can try and do the following..

++ What is configured on the sip-server in sip-ua config?

 Have you tried using the ip address directly on the dial-peer?

++ enable the following..

debug ccsip info

debug ccsip error

debug cccsip transport

[Marko Rodic]

all right!

thanks!

OK, I will do those, but later today(in about 12 hrs), cause right now there is way too many calls to separate this one.

[Marko Rodic]

Problem is resolved. Believe it or not, problem was... DNS :s

And now we have different issue, but thats different story, and will check the logs first and then post another topic if needed...

Thanks for all the help! :)

[Ayodeji Okanlawon]

Glad to help but don't forget to rate any helpful post