cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2515
Views
0
Helpful
9
Replies

What does "LOCAL3.DEBUG: cordless_stop_rtp(), RTP session 0 stopped succussfully\n" mean in SPA122 syslog?

AT57816
Level 1
Level 1

Hi,

 

I am new to the forum. I am trying to find out why some of the ATAs in our system are occasionally locking up and whether there is a relationship between not getting this syslog message "LOCAL3.DEBUG: cordless_stop_rtp(), RTP session 0 stopped succussfully\n" and ATA lock up.

 

I can try to explain my test set up. I have 2 x ATAs - SPA122s with IP addresses 10.1.1.31 and 10.1.1.32 and they both dial the same number to reach a central ATA SPA122 with an IP address 10.1.1.21. Between remote ATAs and the central ATA, I have a proprietary device with an IP address 10.1.20.21 which acts as a Streaming Audio Server (SAS). 

 

We see the following messages when the ATA is working correctly (that is the ATA 10.1.1.31 working fine without locking up):

 

Successfull - 1.PNG

 

When the ATA (10.1.1.32) locks up we see the screenshot below which is similar to the transactions above, except that the syslog message "LOCAL3.DEBUG: cordless_stop_rtp(), RTP session 0 stopped succussfully\n" is missing.

 

lock up - 1.PNG

 

Does anybody know the significance of these messages?

 

All ATAs have the latest FW 1.4.1(SR5)

9 Replies 9

Dan Lukes
VIP Alumni
VIP Alumni

Programmer should know it. But no one at Cisco (I suspect the firmware for SPA12x is maintained by a hired external company). And definitely no one here. We can just guess. I will assume you know how VoIP works and what RTP stands for, so I will not explain it. Based on my experience, the cordless_stop_rtp(), releasing RTP channel:0 message is logged in begin of the function cordless_stop_rtp() and

cordless_stop_rtp(), RTP session 0 stopped successfully is logged when done (just before leaving). Now we know cordless_stop_rtp() doesn't end. Probable because it waits for an event that doesn't happen for some unknown reason (or it has been just missed).

 

I assume the issue is related to RTP. As we have no packet dump of RTP, we can' analyze it for differences. But I see some even without the dump.

1. Calls have no same codec configuration. 

2. streams server doesn't stop sending RTP stream

As we have no dump of SIP we can't analyze details.

 

What can you do? Well, I'd rather describe what I would do.

Capture at least SIP (but better SIP+RTP) and correlate captured packets with the log for better understanding the program flow and meaning of the messages. Compare captured SIP taken from failing call with the one from non-failing call and search for differences.

 

Try to simplify configuration. Company internal phone network needs no support for multiple audio codec. Select one (I recommend you PCMA, or PCMU if you are in US) and disable all others. Note that PCMA/PCMU codec should use ptime:20 so change the configuration accordingly. Verify the streaming server is using the same (e.g. analyze content of SDP in captured SIP dump).

 

Good hunt.

Hi Dan,

 

Thanks for the info. It is a proprietary set up and codec negotiation is done internally. That why you see below that RTP uses codec G729 after negotiation. 

 

Below is a screenshot of the SIP+RTP packets captured by Wireshark. Streaming Server 10.1.20.21 does not stop streaming as it does not receive a bye from the locked ATA 10.1.1.32. My understanding is that both ATAs 10.1.1.31 and 10.1.1.32 that were connected to the Streaming server should send a "Bye" to  stop it from streaming. 

 

Wireshark - lock up.JPG

 

From the Syslog messages, I could see that the the ATA 10.1.1.31 that works correctly (with no lock up) logs the message "LOCAL3.DEBUG: cordless_stop_rtp(), RTP session 0 stopped succussfully\n" and after 0.005455 sec terminates the call with a Bye when it is goes "on-hook". But ATA 10.1.1.32 is locked up and cannot send a Bye even if if is made to go on-hook immediately after the other ATA 10.1.1.31 goes on-hook.

 

I hope that helps to clarify your questions and thanks for your response.

OK. If you have one ATA that works correctly and second one not working correctly, then we need to identify the difference. It may be firmware version and/or configuration. At least configuration is not the same. I see PCMA codec mentioned in .31 SDP but not in .32 SDP. There may be more differences than this one.

 

But as a blind shot - disable G.729 codec on ATA and try again.

Thanks Dan for the response.

 

It is not one specific ATA locking up all the time, occasionally the other ATA 10.1.1.31 locks up when 10.1.1.32 is working correctly. There had been a situation once where all 3 ATAs (10.1.1.21, 10.1.1.31 and 10.1.1.32) got locked up. 

 

In 10.1.1.32 first preferred Codec was set to G711u, second preferred codec was set to G729a, third preferred codec set to unspecified with "Use preferred codec only" setting set to "No". In 10.1.1.31 first preferred Codec was set to G711u, second preferred codec was set to G729a, third preferred codec set to G729a with "Use preferred codec only" setting set to "Yes". That was why G711a and G721 codecs were missing in the invite from ATA 10.1.1.31.

 

Unfortunately, I can't disable G.729 as it is the codec used in our proprietary set up in addition to G711u.

 

Thanks


I can't disable G.729

Disable it for test. If influence of G729 use will be confirmed, you/we can consider further steps then. If the test will not confirm the hypothesis, one of possible causes will be excluded from further considerations.

 

By the way, there is little advance of use of multiple codecs. What value of RTP Packet Size you have configured ? G729 requires 0.03, while best value for G711 is 0.02 (and other values may not work at all or may cause issues). You should consider move from G729 to G711a (or G711u in US) even with no issue we are speaking of about.

Hi Dan,

 

Ok, I will disable G.729 and test again and see how it goes.

 

RTP Packet size is set to 0.03.

 

Thanks again for your assistance.

I'm staying tuned

AT57816
Level 1
Level 1

Hi Dan,

 

I tested with G711u. I didn't see ATA locking up. But, ATA locking up was an occasional issue. So not sure whether it may re-appear in the later testing or not.

 

Also, we had some issues with the timing of the proprietary device that was used instead of the analogue phones. We fixed that too. 

 

Anyway, thanks Dan for your help and prompt response. 

 

Much appreciated.

Glad to hear it helped a lot.