Cannot get connection-reuse to work on SIP-trunk - REGISTER and INVITE are still transmitted on seperate ports

[jswm_mm01]

First of all, I'm far from an expert so bare with me if my questions seems ordinary :-)

We have 10 offices in Europe with a central CUCM 11 and local ISR 4321/4331 gateways running IOS XE 15.5 (or so I believe - an sh run returns version 15.5 in the beginning of the config).

We're in the process of migrating one of our offices in Germany from ISDN phone lines to a SIP trunk with Deutsche Telekom since Telekom is discontinuing ISDN as a product.

We have an external partner helping us and we've been relying much on the following document that describes how it should be done (or at least how it should be done back in 2017):

https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/interoperability-portal/connecting-unified-communication-manager.pdf

It's definitely not been an easy experience and we're still not quite there.

First of all we ran into the problem that the document describes that we should use "registrar dns:sip-trunk.telekom.de expires 240 tcp auth-realm siptrunk.telekom.de" in the sip-ua section.

However sip-trunk.telekom.de doesn't have a DNS record and it should eow be reg.sip-trunk.telekom.de instead. The same is the case for the sip-server command.

But if I change the setup to use reg.sip-trunk.telekom.de instead, the DNS resolves fine but the REGISTER is rejected by Telekom because it then uses @Reg.sip-trunk.telekom.de as FROM domain in it's REGISTER request and that has to be @sip-trunk.telekom.de.

Currently I have a crude work around for this problem where I've created static host entries on the ISR gateway for sip.trunk-telekom.de and reg.sip-trunk.telekom.de so that it can be resolved by the gateway.

And now I'm able to make a correct REGISTER and have the SIP-trunk registered with Telekom and I can also receive calls.

However we cannot call out - when we send an INVITE we get a 403 response from Telekom.

They tell me that the problem is that I'm not using the same connection for my REGISTER and INVITE command and a network trace shows this to be correct (source port is different but the destination port is the same). This is not permitted.

However I already se conn-reuse in my "voice service voip"->"sip" config and I also use connection-reuse in my "sip-ua" config so from my limited knowledge, this should ensure that I use the same port.

What am I doing wrong?

It should be mentioned that Telekom only supports TCP for the requests.

I've attached most of the config to this post.

With regards,

Martin Moustgaard

[Tanner Jackson]

Can you attach a SIP call example that includes the 403 response code?

[jswm_mm01]

Hi Tanner.

Not quite sure if this is what you're asking for, but the attached 2 screendumps are packet traces of the REGISTER request (which is successful) and the following INVITE where I try to dial out.

As you can see it uses 2 different TCP ports and according to Telekom this is the problem - the INVITE needs to reuse the TCP port used by the REGISTER request.

With regards,

Martin Moustgaard

[Vaijanath Sonvane]

Hi,

Can you please post the logs for below commands:

• debug ccsip messages
• debug voip ccapi inout

[jswm_mm01]

Hi Vaijanath.

Is the attached what you're referring to?

With regards,

Martin Moustgaard

[Nuno Melo]

Hello,

The connection reuse should only work for udp traffic , not tcp as per the documentation:

https://www.cisco.com/c/en/us/td/docs/ios/voice/command/reference/vr_book/vr_s11.html

Command Description

connection-reuse

Uses the listener port for sending requests over the User Datagram Protocol (UDP).

TCP connections with CUBE are always sourced from a random ephemeral port. There is
no command to make TCP source from 5060, as there is with UDP. Instead, CUBE makes
use of the built-in connection reuse behavior offered by TCP. If a TCP connection is
already open between CUBE and another device, CUBE reuses that connection for sending
SIP messages even if they are for a different SIP session.

Having said that, the 403 from deutsch telekom can also be triggered if:

• You do not source the traffic from the correct interface, in this case the Internet facing one
• You do not send a vald public number on the outside inviten PAI field
  • I would suggest you enable PAI on CUCM Sip Trunk and also on the cube

From your config there are some configuration i would not recomend

Deutsch telekom Uses DNS srv records to inform the cube where to point the sip traffic, if you hardbind the entries then if they change the ips, your configuration will stop working

ip host sip-trunk.telekom.de 217.0.26.165 <-- This could cause issues if Deutsch teleko cahnges the ips of their sip servers
ip host reg.sip-trunk.telekom.de 217.0.26.165

ip name-server 194.25.0.52  <-- This should be deutsch telekom dns server
ip name-server 192.25.0.68  <-- This should be deutsch telekom dns server

If you configure your dns correctley you should be able to chech the deusch telekom srv recrods on the cube using the show hosts command:t

**Output Example**

Name servers are 217.0.43.129, 217.0.43.145, 217.237.151.142, 217.237.150.188
NAME TTL CLASS TYPE DATA/ADDRESS
-----------------------------------------
b-ipr-a01.edns.t-ipnet.de 1161 IN A xxx.xxx.xxx.xxx
_sip._tcp.reg.sip-trunk.telekom.de 1729 IN SRV 10 0 5060 b-ipr-a01.edns.t-ipnet.de
_sip._tcp.reg.sip-trunk.telekom.de 1729 IN SRV 20 0 5060 b-ipr-a02.edns.t-ipnet.de
_sip._tcp.reg.sip-trunk.telekom.de 1729 IN SRV 30 0 5060 d-ipr-a01.edns.t-ipnet.de

and registration should work,

Regarding your pcap captures, are you geting them directly on the cube or another device?

i had some issues in the past with the source port issue also however everytime i capture the traffic on the cube, the source port although random, is allways the same, most of my deployments use ISR4K routers with the latest IOS, so it could be ios related in your case.

[Tanner Jackson]

I found a similar issue in a previous post where the invite was being rejected with the 403 forbidden and you may want to double check you are providing a valid number to your carrier as Nuno mentioned.

From related post - "As an update, the outgoing calls are working now, I had to change the calling number from extension to DID provided by ITSP (through a translation rule)"

https://community.cisco.com/t5/ip-telephony-and-phones/disconnect-cause-57-in-ccsip-inout-and-disconnect-cause-403/td-p/2890051

[jswm_mm01]

Hi Tanner.

I'm definitely no expert on this topic but when I look at the INVITE (attached is as a picture to this mail) I'm pretty sure we already do this.

Also the reply from Telekoms technical staff was that the INVITE seems to be properly formatted and that they could see that it was rejected because it didn't reuse the TCP connection from the REGISTER.

With regards,

Martin Moustgaard

[jswm_mm01]

Hi Nuno and thank you for your reply.

After reading the documentation earlier today I came to the same conclusion as you regarding the connection-reuse.

However it's specifically mentioned in Ciscos own document that describes how to configure the CUBE and we also got the same instructions once more from TAC today even though we specifically informed them that Telekom uses TCP and not UDP.....

The reason that I currently hardbind the DNS is because of another problem with Telekom.

They insist on using reg.sip-trunk.telekom.de as both proxy and sip-server but the domains etc. used in the headers has to be sip-trunk.telekom.de without reg. as subdomain (actually the Cisco documentation writes that we should use sip-telekom.de as sip-server but there are no DNS records for sip-trunk.telekom.de - neither SRV nor A - so the documentation isn't up-to-date since reg.sip-trunk.telekom.de is the correct server to use).

However if you use reg.sip-trunk.telekom.de in the registrar command in sip-ua, it also uses that domain in the headers.

In the past there was an additional parameter for the registrar command where you could specify the aor-domain, which I presume was for cases like this. However it's been removed years ago so in order for the sip-trunk to register with Telekom we've currently applied this work-around, knowing very well that it only works until Telekom decides to change the IP addresses of their SIP server (currently they seem to rotate the SRV records on an hourly basis).

Regarding DNS servers the I think the Cisco partner made a type in the 2nd one since it should probably by 194. and not 192. but the first one (194.25.0.52) actually was specified in the IP letter we got for the internet connection that Telekom supplied us with instead or our old ISDN PRI connection.

I've also spoken with the tech department at Telekom who looked at the log files in their end (I tried to make 2 calls with the SIP trunk where they then analyzed it from their end) and their feedback was that they rejected it because the INVITE didn't use the same TCP port as the REGISTER and not because the INVITE was malformed. I will, however, try to look into your suggestions regarding PAI just to rule that one out.

The traffic I captured was directly on the ISR unit using the build in monitor capture.

You do raise a valid question regarding us not running latest IOS so I'll bring that up with our Cisco partner tomorrow.

With regards,

Martin Moustgaard

[jswm_mm01]

Hi Nuno.

One quick question: You write that a reason for the 403 could be that we do not source the traffic from the correct interface, in this case the Internet facing one.

I'm no expert in network traffic but the package captures I have of the 403 shows our public IP as source address of the INVITE (and REGISTER) so shouldn't this be OK?

With regards,

Martin Moustgaard

[Nuno Melo · Accepted solution]

I'm no expert in network traffic but the package captures I have of the 403 shows our public IP as source address of the INVITE (and REGISTER) so shouldn't this be OK?

In your case yes you are sourcing the traffic from the correct interface

The reason why i asked also if you where capturing the traffic on the cube or on another device is that the port could be changed by an additional equipment that is processing L3 Packets. Since this is not the case your cube is definitely changing the source port of the tcp packets and therefor telekoms assessment seems to be correct.

I attach my config, its a bit more complex since i am using tenants, but from my cube captures the tcp source port is consistent on all sip invites 

[jswm_mm01]

Hi Nuno.

Thank you for sharing the config.

One question: You have dns:sip-trunk.telekom.de listed as the sip-server and also on registrar. How do you resolve this DNS wise since I cannot resolve it to anything (no SRV or A record)?

With regards,

Martin Moustgaard

[Nuno Melo]

One question: You have dns:sip-trunk.telekom.de listed as the sip-server and also on registrar. How do you resolve this DNS wise since I cannot resolve it to anything (no SRV or A record)?

Im using the following name dtag name servers 217.0.43.129  and  217.0.43.145

Once the SIP-UA or Tenant triggers the registration requests the resolution happens, this request goes to reg.sip-trunk.telekom.de because of the outbound-proxy command (outbound-proxy dns:reg.sip-trunk.telekom.de) once the register request is sent to the provider dns, cube should query all the required A records and srv records automatically. you can check this via a packet capture on the cube or using the comand "debug ip domain detail", if the resolution is successfull you can do "show hosts" to check the Cube dns cache.

[jswm_mm01]

Hi Nuno.

I don't know if it's related to my version of IOS but when I use reg.sip-trunk.telekom.de as proxy and sip-trunk.telekom.de as registrar and sip-server, then no REGISTER is sent.

And I can see from my package trace that first it tries to resolve the SRV record for _sip._tcp.sip-trunk.telekom.de (using 217.0.43.129 as DNS server) and when this fails it then tries to lookup the A record for sip-trunk.telekom.de which also fails and therefore no REGISTER request is transmitted.

So if the purpose of the proxy is for the requests to the proxy who the processes it, then this doesn't seem to work in my case.

And since we're running 15.5 tenants is not an option since it wasn't included until 15.6 as far as I can see.

Our Cisco partner has scheduled a remote session with a TAC engeneer tomorrow and I really hope they can get to the bottom of this because this is driving me nuts right now (not to mention annoying the hell our of the office in Germany who currently have very limited phone capabilities).

With regards,

Martin Moustgaard

[Nuno Melo]

I don't know if it's related to my version of IOS but when I use reg.sip-trunk.telekom.de as proxy and sip-trunk.telekom.de as registrar and sip-server, then no REGISTER is sent.

And I can see from my package trace that first it tries to resolve the SRV record for _sip._tcp.sip-trunk.telekom.de (using 217.0.43.129 as DNS server) and when this fails it then tries to lookup the A record for sip-trunk.telekom.de which also fails and therefore no REGISTER request is transmitted.

If you do not see a dns cache on the router use the show hosts commands, then most probably you are having dns resolution issues, do you have some firewall between the cube and the internet access that could be blocking the dns resolution

Additionally the registration does not happen right away it only happens when the expires timer hits "0" using the command show sip-ua register status you can check this also.