cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays
269
Views
5
Helpful
3
Replies
Mark Boiston
Beginner

Incoming SIP calls fail to connect then get represented to the phone

Hello.

We have a 2921 gateway on a site in the Netherlands. It is currently running with an E1 TDM connection to the PTT.

It is also connected to a centralised CUCM.

We are changing the external access to be a SIP trunk from the gateway to the PTT.

 

Outgoing calls from a softphone through the gateway to the PTT over the SIP trunk work well.

But incoming calls fail.

The call comes in over the SIP trunk and is presented to the softphone. You can answer the call but it doesn't fully connect.

The called extension thinks the call is there but the external caller still gets ringing.

After a few seconds the call gets represented to the softphone as a second call even though the first one is still active.

I have been through the config and cannot see what is stopping the call from connecting fully when it is answered.

 

I have attached some files to show what is happening.

I have taken some traces (voip ccapi and ccsip all) and a colleague on site has also managed to get some wireshark traces of these calls. I also have the full running config and a copy of a trace that the PTT sent to me showing what they see.

 

As I don't fully understand what the traces are showing can someone please have a look at them and let me know if the gateway config is incorrect or if I have missed something, if the messages suggest what the problem is, or even if it looks like the PTT is causing it?

 

Thanks very much

1 ACCEPTED SOLUTION

Accepted Solutions
Scott Leport
Participant

Hi there,

 

From the ccapi info you provided, the disconnect cause code is 47 as per example below:

*Dec 7 17:05:07.786: //7257/2D0435099C72/CCAPI/cc_api_call_disconnected:
Cause Value=47, Interface=0x3EC93760, Call Id=7257

 

The reason for those disconnects are usually codec mismatch or media resource related, e.g. it's looking for a Media Termination Point or Transcoder, but can't allocate one. That could be related to your MRG / MRGL configuration in CUCM.

Based on the info you've supplied it looks like you have SIP from the gateway and H.323 to your CUCM. You may need to enable Fast Start on your H.323 gateway configuration in CUCM if you want to keep that configuration in place. Personally though I would consider changing that configuration to a SIP trunk from CUCM to the CUBE as you have less chance of running into other interoperability issues.

If you wanted to run this parallel to your existing H.323 setup, you could configure a SIP trunk from CUCM and point it to another interface on your gateway / CUBE (either Gig0/2 or a loopback) and bind the SIP signalling and media on that interface.

 

You would also need to ensure the dial-peers facing CUCM would also need to be converted to SIP, but in this testing phase you could configure a dial-peer on your gateway to a specific DN (test phone or spare phone perhaps) on your network and test incoming calls to it.

 

View solution in original post

3 REPLIES 3
Scott Leport
Participant

Hi there,

 

From the ccapi info you provided, the disconnect cause code is 47 as per example below:

*Dec 7 17:05:07.786: //7257/2D0435099C72/CCAPI/cc_api_call_disconnected:
Cause Value=47, Interface=0x3EC93760, Call Id=7257

 

The reason for those disconnects are usually codec mismatch or media resource related, e.g. it's looking for a Media Termination Point or Transcoder, but can't allocate one. That could be related to your MRG / MRGL configuration in CUCM.

Based on the info you've supplied it looks like you have SIP from the gateway and H.323 to your CUCM. You may need to enable Fast Start on your H.323 gateway configuration in CUCM if you want to keep that configuration in place. Personally though I would consider changing that configuration to a SIP trunk from CUCM to the CUBE as you have less chance of running into other interoperability issues.

If you wanted to run this parallel to your existing H.323 setup, you could configure a SIP trunk from CUCM and point it to another interface on your gateway / CUBE (either Gig0/2 or a loopback) and bind the SIP signalling and media on that interface.

 

You would also need to ensure the dial-peers facing CUCM would also need to be converted to SIP, but in this testing phase you could configure a dial-peer on your gateway to a specific DN (test phone or spare phone perhaps) on your network and test incoming calls to it.

 

View solution in original post

Hello Scott

 

I checked the things you mentioned above.

The Enable Faststart parameter wasn't set on the gateway config on the CUCM. I amended that and the calls are working correctly now.

 

Thanks very much for your help

Scott Leport
Participant

Hi Mark,

 

Glad to hear it and happy to help.

 

Good luck with the SIP cutover.

 

Regards,


Scott

Content for Community-Ad

Spotlight Awards 2021