Author Topic: How to collect the debugging information?  (Read 1372 times)

ogogon

  • Newbie
  • *
  • Posts: 11
    • View Profile
How to collect the debugging information?
« on: March 04, 2016, 03:11:29 PM »
Dear colleagues, please tell me, how do I do the right thing in my case.

I have unexpected break of sessions, and I want to understand what the cause.

Architecture of constructed system is not entirely typical. This is caused by reasons that we can not change, and under who are forced to adapt.
We have an operator who does not want to take into consideration our technical specifics.
If support of CID is turn on, operator sends incoming invites in the RFC-3966 format, and softswitch Asterisk, that we use, does not understand this format. He does not accept these invites.
Now we are working with the CID off, but we need to turn it on.

Operator's Huawei <---> Asterisk

In order to get ready for the turn on of CID, we have created a transit softswitch. It Yates, who supports RFC-3966 format. He registers on the operator softswitch and transparently transmits calls to Asterisk.

Operator's Huawei <---> Yate <---> Asterisk

So we have an architecture that performs its task.

Unfortunately, after the iinclution of a transit unit in the form Yate, came an unexpected and unpleasant effect.
Sometimes, through different times, the connection is broken. Without Yayte this does not happen.
I want to collect debugging information and understand where it comes from a request for disconnection.

How to in Yate save SIP-session of selected SIP-account, or, better yet, all the debug information of sessions?


Advance grateful for the answer on the subject matter,
Ogogon.
« Last Edit: March 05, 2016, 01:42:22 PM by ogogon »

Ioana Stanciu

  • Jr. Member
  • **
  • Posts: 57
    • View Profile
Re: How to collect the debugging information?
« Reply #1 on: March 07, 2016, 02:23:43 AM »
Please checkout http://docs.yate.ro/wiki/Debugging_in_Yate

You probably need to turn on debug on SIP also ('debug sip level 10' command in telnet console).

Also, a wireshark capture can help.

ogogon

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: How to collect the debugging information?
« Reply #2 on: March 07, 2016, 09:24:16 AM »
Quote from: Ioana Stanciu
Please checkout http://docs.yate.ro/wiki/Debugging_in_Yate

You probably need to turn on debug on SIP also ('debug sip level 10' command in telnet console).
Thank you. I have read this document for a long time.
Unfortunately, I did not find in it the answer to my question.

Maybe I was not careful, but I do not understand from him how to enable debugging only for one SIP system.

For example, Asterisk is done with a single command:
sip set debug peer peer_name

Is there any possibility at Yates?

Quote from: Ioana Stanciu
Also, a wireshark capture can help.

Thank you. Sure, I can use an external sniffer, but I was hoping that Yate has a flexible functional of debugging.
External sniffer is not as good - for him, in my case, I need to write quite complex filters.
In addition, tсpdump and his relatives may lose a part of a package, but a built-in debugger - never.

Ogogon.

marian

  • Sr. Member
  • ****
  • Posts: 384
    • View Profile
Re: How to collect the debugging information?
« Reply #3 on: March 08, 2016, 02:27:34 AM »
You can't filter debug based on sip account.
You should stick with Wireshark (if possible) and yate log.
You should use yate log to see what happens when a connection is lost.
And what do you mean by connection lost: sip call hangup or some TCP connection break?

ogogon

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: How to collect the debugging information?
« Reply #4 on: March 10, 2016, 07:39:01 AM »
You can't filter debug based on sip account.
Regrettably.

Quote from: marian
You should stick with Wireshark (if possible) and yate log.
You should use yate log to see what happens when a connection is lost.
Unfortunately, nothing else to do.

Quote from: marian
And what do you mean by connection lost: sip call hangup or some TCP connection break?
I had to disable the remaining twenty SIP-accounts to get more or less readable log.
From the log of the account that was used as a test, it became clear that the operator suddenly has sent SIP-command "BYE".
Operator already have confirmed that the problem is on their side. Now they are all gone to think about why this is happening.

By the way, when instead Yate registered Asterisk, this does not happen.

Ogogon.