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

[jswm_mm01]

Hi Nuno.

That sound odd because how can you register the sip-trunk without a register request - are you running in static mode by any chance?

Cisco TAC has asked us to upgrade the IOS to a version that supports tenants - will try to do so during the weekend and change the configuration to one where adopt tenants and then we'll see how that goes.

Will write my findings here once I know more.

With regards,

Martin Moustgaard

[Nuno Melo]

That sound odd because how can you register the sip-trunk without a register request - are you running in static mode by any chance?

No, dns resolution in my case is just the ip-name servers pointing to deutsch telekom i do not have any fixed host entries on the cube.however in my case the dns resolution works with no issues, i see the dns requests leaving the cube and i receive successfully the reply's from deutsch telekom

I do have a register requests, these are sent periodically to the isp and  this is actually what triggers the initial dns resolution on the cube.

what i ment in my previous post, is that it seems that in your case your dns resolution is not working correctly witch would then affect your registration process, since you mentioned that you do not receive a reply after the dns querys.

"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."

Regarding the IOS upgrade i also think its a good idea, since the last ios versions for the ISR G2 series have a lot of improvements for the sip stack.

[jswm_mm01]

Hi Nuno.

I've now upgraded to 16.9 and are therefore able to use tenants, which seems to have helped a lot after I've altered our config to use tenants (the upgrade alone didn't do it - we had to use tenants to get it to work).

We now send the INVITE on the same port as the REGISTER requests and I no longer have to have static host entries in the configuration.

So my guess is that even though we had a proxy registered with the old config used with version 15.5, it wasn't being used for the INVITEs. That would also explain the odd attempts of trying to resolve an SRV record for _sip._tcp.sip-trunk.telekom.de

So now we can register the trunk and receive calls and we can also initiate an outgoing call that's actually being accepted by Telekom.

However we still have one problem left and that is that when we dial out, the phone rings 1 time in the other end and then the connection is cut.

As far at I can see it's our end that sends a CANCEL request to Telekom and not the other way around so we must have something that's still not configured correctly. However when I look at the Call Flow Diagram in Real Time Monitoring it looks like it's the client that sends the CANCEL request so I believe that the remaining problem isn't related to the sip-trunk configuration but instead be somewhere in the Callmanager configuration. So I'm looking forward to having our Cisco partner look into this problem tomorrow.

Thank you very much for sharing your knowledge with me in this case.

With regards,

Martin Moustgaard

[Nuno Melo]

No problem, glad it helped

[MrStinch01]

Hi,

Do you have a sanitized working example of your working cube config? Ours was working, then intermittently outbound calls stopped working this year. Cisco just made us upgrade from 16.09.03 to 16.09.05 and all I get now is the 403 message. I am also trying to get call forwarding to external numbers working (eg to a users mobile phone); but when answered there is no audio. Curious if you have that issue as well as it is the same provider. 

Many Thanks,

Mike 

[b.winter]

Hello Martin,

I'm not sure, if the discussion about the "connection-reuse" is already clarified or not, but maybe my comments help you or others.

First:

There are 2 different commands for TCP and UDP

For TCP --> conn-reuse

For UDP --> connection-reuse

Second:

If using tenant and a UDP connection, the command "connection-reuse" MUST be configured before the "registrar ..." command is configured.

If the "registrar ..." command is configured first, CUBE sends out the REGISTER with a random port, and makes it constant with the "connection-reuse".

Example:

voice class tenant 100

 connection-reuse (via-port)

 registrar dns:<Registrar-Server> ...

Third:

When connecting to a SIP Provider and have to use UDP, I also always use the parameter "via-port" for the "connection-reuse".

What it this is, it always uses port 5060 for any SIP messages.

Fourth:

A lot of providers, which I have worked with, have a problem with external inbound calls, that are forwarded back to external:

External 1 --> CUBE --> CUCM --> CUBE --> External 2

The problem are their SIP platforms. They have the "feature", that they only send RTP-packets, only after they received one from the opposite endpoint.

In normal calls, the endpoint is the phone --> no problems.

But in forward calls, the RTP is basically sent from / to provider. Since the platform waits for itself to receive RTP-packets, before sending, it doesn't send anything at all --> No-Way-Audio.

The best solution for all SIP Provider integration is, to use a public IP directly on the CUBE.

Or:

The easiest way to solve this, by activating MTP on the SIP trunk pointing between CUCM and CUBE. But make sure, that the software MTP of CUCM is used, since its the only device, which sends out empty dummy RTP-packets.

HW-MTP on CUBE won't work.

But it's not a gentle solution, since it uses CUCM as RTP relay --> needs CPU.

Or:

Configure STUN. Especially in situtations, where CUBE only has a private IP and there is a NAT device in front (before going out to the internet)

voice service voip

 stun

  stun flowdata agent-id 1 boot-count 13

  stun flowdata shared-secret <pwd> --> can be anything

!

voice class stun-usage 1

 stun usage firewall-traversal flowdata

!

dial-peer voice x voip

 description ### From / To Provider ###

 voice-class stun-usage 1

Or:

Try the command "media anti-trombone" in "voice service voip"

PS:

If you need a working config for Deutsch Telekom in Germany, just ping me.