No problem, glad it helped ... View more

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.   ... View more

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. ... View more

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.     ... View more

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. ... View more