Solved: PRA/PRI signalling to SIP Issue - Call does not disconnect

Sajid Qureshi · ‎02-16-2017

Dear All,

I will really appreciate if anybody please help me!

I am using cisco 2621xm with NM-HDV-2E1-60 module and I have connected 2 E1s from teleco. I can make calls successfully without any issue but I am facing one issue, when call is disconnected by the called party, cisco does not send a disconnect/release message to SIP server.

The complete call scenario is:

I make call from IP-Phone wich is registered with my SIP server. Call from SIP server goes to the cisco router and cisco calls out using E1 connected to it. When we finish conversation, the called party hangs the line and I get release message from ISDN side. After getting release message from teleco/ISDN side, cisco does not forward it to SIP server. Hence, my IP-phone and SIP server shows that the call is still active.

I contacted to teleco and they have told me that:

"Our system used the q931 protocol for exchanging PRA/PRI signaling with the peer device. If the called party disconnects a call, a “Disconnect” message will be sent to the peer device indicating that the call has been released. The peer device will then acknowledge that the call has been released by sending a “Release” message. Since you device is responding correctly on the signaling link, your router should be able to translate the PRA/PRI signaling to SIP signaling"

can anybody please advise me how can I sort this out in cisco?

Best Regards,

Sajid

Jay Schulze · ‎02-16-2017

Thanks for running those.

So you can see what is going on here. Immediately after the release message from the PRI. You see the bye being sent from the gateway to the sip-server. However there is no 200ok from the sip-server. And the gateway continues to send byes with no response.

I don't see a problem on the gateway side here and not sure what type of sip server you are running. But I don't believe the problem is on the gateway side. What should be happening is the call agent receives the bye. send 200 back to the gateway. And the call agent sends bye to the phone. One thing I don't like seeing is the gateway and sip server using different ports. I don't think that is the problem as we see it responding to the 183. But would be worth trying to synch those up to both use 5060.

View solution in original post

Jay Schulze · ‎02-16-2017

There are a couple things could be happening here. But we'll start with my rule number 1 - never trust the provider :). (no offense to providers). A lot of time their expectations and yours are different.

So do this. Make a call and disconnect while running 'debug isdn q931' and 'debug ccsip message'.

We'll be able to tell what is happening from that.

J

Sajid Qureshi · ‎02-16-2017

Hi Jay,

Thank you for reply.

Please see attached ccsip and below debug isdn q931:

*Mar 1 00:05:43.031: ISDN Se1/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0081
        Sending Complete
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA9839F
                Exclusive, Channel 31
        Calling Party Number i = 0x0080, 'calling number'
                Plan:Unknown, Type:Unknown
        Called Party Number i = 0x80, 'called number'
                Plan:Unknown, Type:Unknown
*Mar 1 00:05:43.155: ISDN Se1/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x8081
        Channel ID i = 0xA9839F
                Exclusive, Channel 31
*Mar 1 00:05:46.059: ISDN Se1/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x8081
        Progress Ind i = 0x8288 - In-band info or appropriate now available
*Mar 1 00:05:53.891: ISDN Se1/0:15 Q931: RX <- CONNECT pd = 8 callref = 0x8081
        Progress Ind i = 0x8284 - Call has returned to the ISDN
        Date/Time i = 0x110210120F3B
*Mar 1 00:05:53.895: %ISDN-6-CONNECT: Interface Serial1/0:30 is now connected to called number N/A
*Mar 1 00:05:53.899: ISDN Se1/0:15 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0081
*Mar 1 00:06:04.883: %SEC-6-IPACCESSLOGRL: access-list logging rate-limited or missed 7 packets
*Mar 1 00:06:14.451: ISDN Se1/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x8081
        Cause i = 0x8090 - Normal call clearing
*Mar 1 00:06:14.455: ISDN Se1/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x0081
*Mar 1 00:06:14.571: ISDN Se1/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8081
*Mar 1 00:06:14.575: %ISDN-6-DISCONNECT: Interface Serial1/0:30 disconnected from called number , call lasted 20 seconds

These are for 2 different calls. In both cases, call was disconnected by called party but ip-phone/SIP server was still showing active call.

Regards,

Sajid

Jay Schulze · ‎02-16-2017

Thanks for running those.

So you can see what is going on here. Immediately after the release message from the PRI. You see the bye being sent from the gateway to the sip-server. However there is no 200ok from the sip-server. And the gateway continues to send byes with no response.

I don't see a problem on the gateway side here and not sure what type of sip server you are running. But I don't believe the problem is on the gateway side. What should be happening is the call agent receives the bye. send 200 back to the gateway. And the call agent sends bye to the phone. One thing I don't like seeing is the gateway and sip server using different ports. I don't think that is the problem as we see it responding to the 183. But would be worth trying to synch those up to both use 5060.

Sajid Qureshi · ‎02-17-2017

hi Jay,

I thought so too after looking ccsip results. I did not debug ccsip before.

I think our external firewall is blocking the communication with cisco or probably it will be fixed by synching sip ports.

I will let you know what happened after allowing cisco ip fully in firewall.

Thanks for support.

Regards,

Sajid

Sajid Qureshi · ‎02-20-2017

Hi Jay,

After adding more required ports in our firewall, BYE msgs from CISCO are reaching correctly to our SIP server. Thanks for help.

Regards,

Sajid