cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2801
Views
5
Helpful
19
Replies
jswm_mm01
Beginner

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

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

 

 

19 REPLIES 19

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

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.

 

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

No problem, glad it helped

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 

Content for Community-Ad

Spotlight Awards 2021