Showing results for 
Search instead for 
Did you mean: 

SX20 and ISDN Link with TC6

Adrian Lazar
Level 1
Level 1

Hi guys,

I have recently upgraded an SX20 and ISDN Link to the new TC6 and after the upgrade I cannot make ISDN calls anymore.

I can see and manage the ISDN Link from the SX20 configuration web page but the status of the ISDN Link is: Error , SIP not registered.

I am using H323 in the network and I only use SIP between the SX20 and ISDN Link and with the old version I was able to receive and make calls. Now when I try to dial ISDN using the new TC6 interface the endpoint says that it does not find the ISDN Link.

Thank you for your assistance,


22 Replies 22

Thanks Patrick and Valentin

I removed all the dummy SIP configuration and used the H320 protocol to dial out and it worked. I was able to call my mobile.

So if SIP is not used anymore between the SX20 and ISDN Link this means we can safely disable it on the SX20 Network Services ?



Hi Adrian,

You could keep SIP services if you need SX20 to use also SIP connections to other EPs.

If you use only H.320 protocol, SIP service is not needed to be activated on Network Services . 

Hi Valentin,

If you disable SIP from Network Services the status of the ISDN Link will become "Error - Not registered to H320 device" and the option of using H320 to dial out will dissapear. This makes me think that SIP is still used between the SX20 and ISDN Link.





same issue is with me i have disabled all sip settings in menu options still it showing me error in isdn link status

Rather than adding a question to a 12 month old, "Answered" thread - I suggest you create a new one to deal with your issue.

Remember to post as much detail about your devices and setup as possible to help us to assist you (models, versions, connectivity, etc).

Please remember to rate responses and to mark your question as answered if appropriate.


Please remember to mark helpful responses and to set your question as answered if appropriate.

Patrick Pettit
Cisco Employee
Cisco Employee

Hi Guys. Slow down for a minute before we start disabling things. Adrian is right. SIP is still used in this scenario even with IL 1.2. Will explain in further when I get to a keyboard.

@Adrian , you good with disabling SIP outbound on Link and SX20 and removing the dummy settings we used to right?


Sent from Cisco Technical Support Android App

Patrick Pettit
Cisco Employee
Cisco Employee

Hi Adrian, Valentin.  Theres something going on with Outbound enabled on the Link and Codec for this, and we have two CDETS open on them.  SIP service is still required to be enabled on the Codec with Link and Link itself.  Codec uses Links local IPV6 to register to the Link itself.  Even though the xstatus sip on the codec shows its inactive etc, the codec is still sending SIP REGISTER messages to the Link device for registration.  Link is running a SIP FWD process in which is handling the request.  Sorta like a mini SIP registrar if you will.  Codec will send REGISTER message using Link's local IPV6 address.  Example message is below with 200 Ok.

77582.64 SipPacket   PacketDump: Proto: SIP, Name: REGISTER sip:[0000::000:0000:0000:cd39]:15070 SIP/2.0, Direction: Outgoing, RemoteAddress:[0000::000:0000:0000:cd39]:15070, GroupEntity: b27d07c1f5f298c492db68040b320ca6, Time: 77582634, Content: !!!<

77582.64 SipPacket   REGISTER sip:[0000::000:0000:0000:cd39]:15070 SIP/2.0

77582.64 SipPacket   Via: SIP/2.0/TLS [fe80::250:60ff:fe83:c52a]:5061;branch=z9hG4bK45a7681a50ebbdc5b98e2f91bff6b438.1;rport

77582.64 SipPacket   Call-ID: b27d07c1f5f298c492db68040b320ca6

77582.64 SipPacket   CSeq: 47083 REGISTER

77582.64 SipPacket   Contact:


77582.64 SipPacket   From: ;tag=116a994ac2281c72

77582.64 SipPacket   To:

77582.64 SipPacket   Max-Forwards: 70

77582.64 SipPacket   Route: <>


77582.64 SipPacket   User-Agent: TANDBERG/518 (TC6.0.0.876266)

77582.64 SipPacket   Expires: 3600

77582.64 SipPacket   Authorization: Digest nonce="d9605a7da8be22af8c0e7f52b3de4a5f5125fcd3", realm="MARCIE", qop=auth, username="djkvvknn", uri="sip:[0000::000:0000:0000:cd39]

", response="3b27b753cb9bcf38cc2431b767bce643", algorithm=MD5, nc=00000002, cnonce="84addca2a68f6c5f9b657a94653a4bae"

77582.64 SipPacket   Supported: replaces,100rel,timer,gruu,path,outbound

77582.64 SipPacket   Content-Length: 0

77582.64 SipPacket

77582.64 SipPacket   >!!!


77582.65 SipPacket   SIP/2.0 200 OK

77582.65 SipPacket   Via: SIP/2.0/TLS [fe80::250:60ff:fe83:c52a]:5061;branch=z9hG4bK45a7681a50ebbdc5b98e2f91bff6b438.1;rport=41246;received=0000::000:0000:0000:c52a

77582.65 SipPacket   Call-ID: b27d07c1f5f298c492db68040b320ca6

77582.65 SipPacket   CSeq: 47083 REGISTER

77582.65 SipPacket   From: ;tag=116a994ac2281c72

77582.65 SipPacket   To: ;tag=e84d13204776ebc2

77582.65 SipPacket   Server: fwd

77582.65 SipPacket   Contact: ;+sip.instance=""

77582.65 SipPacket   Content-Length: 0

77582.65 SipPacket

77582.65 SipPacket   >!!!


I removed my own addresses, so you get the picture here. 

Same goes for Link.  Link will send REGISTER to itself as well. 

Even though your using H320 as dial out protocol, the messaging between the codec and the Link device is still SIP as the outbound call is still SIP from the codec to the Link even though you chose H320. 

You can see all this going on whilst running: log ctx sippacket debug 9 and log output on to see the messaging going back and forth between the devices.  This is why SIP Service on the codec can not be disabled.

The outbound being enabled on both devices and it not registering like what Adrian encountered is odd. So issue has been filed and is under investigation.

CSCue57128 -SIP in strange state when connecting to ISDN Link (Codec)

CSCue73049 -Enabling SIP outbound on ISDN Link causes it to lose registration (Link)

These are new, so viewability may not be there yet.

If you see an issue with Link not being able to register, check to see if SIP outbound is enabled on Link.  If so, disable and boot.

Do the same on the codec as well.  Turn off SIP Outbound and reboot.  There may be some instances you don't see this, so the investigation is ongoing with the above two bug ID's.

Hope this helps.