Solved: SIP trunk to provider dropping calls

rynard.coetzee · ‎05-29-2012

Hi

I have the following setup CUCM 6 -- > H323 GW ---- > SIP from same GW ---- > SIP provider

WHen i dial a number across the SIP provider the number rings ,but as soon as i answer the call the call gets dropped ,but from the SIP debugs on the gateway i can not see any reason for it ,the codec negotiation goes through fine ,only error is see is :

May 29 14:59:18: //-1/xxxxxxxxxxxx/SIP/Error/sipSPIUcccause_to_sipcause: Unknown PSTN cause code from CCAPI:0

Spoke to the SIP provider and he reckons he sees a disconnect from my side.

I will attach a copy of the sip debug

Does anyone know what the issue might be here ?

Ayodeji Okanlawon · ‎05-30-2012

Rynard,

Also for future purposes and for otheres who may have similar problems,

If we look at the output of debug ccsip all..we see the following:

++Call leg 2:the outbound call to sip provider:negotiated G729br8++

*May 30 09:22:48: //706482/1329D3BCB4BE/SIP/Info/ccsip_update_srtp_caps: 5033: Not Sending NULL SRTP CAPS to SIP LEG

*May 30 09:22:48: //706482/1329D3BCB4BE/SIP/Media/sipSPIUpdCallWithSdpInfo:

Stream type : voice+dtmf

Media line : 1

State : STREAM_ADDING (2)

Stream address type : 1

Callid : -1

Negotiated Codec : g729br8, bytes :20

Nego. Codec payload : 18 (tx), 18 (rx)

Negotiated DTMF relay : rtp-nte

Negotiated NTE payload : 101 (tx), 101 (rx)

Negotiated CN payload : 0

Media Srce Addr/Port : [41.76.57.125]:0

Media Dest Addr/Port : [82.199.73.139]:19694

++Call leg 1 the inbound leg from CUCM++Negotiated no codec..

*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Call/sipSPIMediaCallInfo:

Number of Media Streams: 1

Media Stream : 1

Negotiated Codec : No Codec

Negotiated Codec Bytes : 0

Nego. Codec payload : 255 (tx), 255 (rx)

Negotiated Dtmf-relay : 0

Dtmf-relay Payload : 0 (tx), 0 (rx)

Source IP Address (Media): 41.76.57.125

Source IP Port (Media): 18604

Destn IP Address (Media): -

Destn IP Port (Media): 0

Orig Destn IP Address:Port (Media): [ - ]:0

*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/sipSPI_ipip_handle_channel_info:

CCSIP:callid 706481 state STATE_SENT_ALERTING

*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/sipSPI_ipip_copy_channelInfo_to_sdp:

callid 706481, channels 0x691A957C caps 0x68BEE744

*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/sipSPI_ipip_copy_channelInfo_to_sdp: Peer cap provided: callid = 706481, peer dtmf = 6

*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/codec_found:

Codec to be matched: 12

*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/sipSPI_ipip_copy_channelInfo_to_sdp:

need transcoding for codec mismatch

*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/sipSPIDtmfTranscoder: Return upon SCCP version 0

*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/ccsip_set_cc_cause_for_spi_err: Categorized cause:65, category:278

*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Error/sipSPI_ipip_copy_channelInfo_to_sdp:

filter mis-match, failing call

*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/sipSPIInitiateDisconnect: Initiate call disconnect(65) for incoming call

*May 30 09:22:48: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_set_release_source_for_peer: ownCallId[706481], src[6]

*

++++and inbetween we see why+++++

CCSIP here informs us that the incoming leg has a different codec to the outboud leg, hence a xcoder is needed. I Believe and MTP device will do the job also

*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/sipSPI_ipip_handle_channel_info:
CCSIP:callid 706481 state STATE_SENT_ALERTING
*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/sipSPI_ipip_copy_channelInfo_to_sdp:
callid 706481, channels 0x691A957C caps 0x68BEE744
*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/sipSPI_ipip_copy_channelInfo_to_sdp: Peer cap provided: callid = 706481, peer dtmf = 6
*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/codec_found:
Codec to be matched: 12
*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/sipSPI_ipip_copy_channelInfo_to_sdp:
need transcoding for codec mismatch
*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/sipSPIDtmfTranscoder: Return upon SCCP version 0
*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/ccsip_set_cc_cause_for_spi_err: Categorized cause:65, category:278
*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Error/sipSPI_ipip_copy_channelInfo_to_sdp:
filter mis-match, failing call
*May 30 09:22:48: //706481/1329D3BCB4BE/SIP/Info/sipSPIInitiateDisconnect: Initiate call disconnect(65) for incoming call
*May 30 09:22:48: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_set_release_source_for_peer: ownCallId[706481], src[6]

Please rate all useful posts

View solution in original post

Ayodeji Okanlawon · ‎05-29-2012

Hi,

The provider is correct..You are sending the disconnect..

May 29 14:59:18: //704239/8023EAEA5211/SIP/Transport/sipSPISendBye: Sending BYE to the transport layer
*May 29 14:59:18: //704239/8023EAEA5211/SIP/Transport/sipSPIGetSwitchTransportFlag: Return the Dial peer configuration, Switch Transport is FALSE

**May 29 14:59:18: //704239/8023EAEA5211/SIP/Info/sentByeDisconnecting: Sent Bye Request, starting DisconnectTimer
*May 29 14:59:18: //704239/8023EAEA5211/SIP/State/sipSPIChangeState: 0x68080F80 : State change from (STATE_DISCONNECTING, SUBSTATE_NONE) to (STATE_DISCONNECTING, SUBSTATE_NONE)
*May 29 14:59:18: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:SIP@82.199.73.139:5060 SIP/2.0
Via: SIP/2.0/UDP 41.76.57.125:5060;branch=z9hG4bK4151319
From: <27112057000>;tag=36BBD418-CBC
To: <27726157245>;tag=606d1152a9d26fd
Date: Tue, 29 May 2012 12:59:08 GMT
Call-ID: E968E27B-A8C411E1-A786BA0C-B5C99641@41.76.57.125
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Reason: Q.850;cause=0
Content-Length: 0

*May 29 14:59:18: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:SIP@82.199.73.139:5060 SIP/2.0
Via: SIP/2.0/UDP 41.76.57.125:5060;branch=z9hG4bK4161DB6
From: <27112057000>;tag=36BBD418-CBC
To: <27726157245>;tag=606d1152a9d26fd
Date: Tue, 29 May 2012 12:59:08 GMT
Call-ID: E968E27B-A8C411E1-A786BA0C-B5C99641@41.76.57.125
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Timestamp: 1338296358
CSeq: 102 BYE
Content-Length: 0

We need to look at your config to have an idea of why this is happening...

Please rate all useful posts

rynard.coetzee · ‎05-29-2012

Relevant configs added

voice service voip

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

allow-connections sip to sip

fax protocol cisco

sip

bind control source-interface Loopback111

bind media source-interface Loopback111

dial-peer voice 19 voip

destination-pattern 27T

no voice-class sip early-offer forced

session protocol sipv2

session target ipv4:xxxx

dtmf-relay rtp-nte

codec g729br8

!

dial-peer voice 20 voip

session target ipv4:10.240.20.11

incoming called-number 27T

dtmf-relay h245-alphanumeric

no vad

Ayodeji Okanlawon · ‎05-29-2012

Can you send a debug voip ccapi inout...I need to see what dial-peeers are matched for the call. Do a test call again and send only debug voip ccapi inout.

Please rate all useful posts

Ayodeji Okanlawon · ‎05-29-2012

Hi,

I also observed that when theprovide sent a 200 ok with SDP, the ack sent does not have any SDP in it. Since yoo are doing delayed offer, you need to ACK with SDP to the 200 Ok sent by the telco. I believe you have some configuration issues

Please rate all useful posts

rynard.coetzee · ‎05-29-2012

I will have to do a debug ccapi after hours as that GW is quite busy during OH .

Ayodeji Okanlawon · ‎05-29-2012

Can you try and remove codec g729br8 from dial-peer 19 and try again...

Why are you doing h323 from cucm to gateway? Why not sip all the way?

Please rate all useful posts

rynard.coetzee · ‎05-29-2012

I tried with G729r8 ,but from the SIP debugs i could see that the SIP provider was trying to use G729br8 ,i had it setup as SIP straight from CUCM server ,but had different issues ,so i tried H323 as a test. When i did SIP from CUCM to GW i could not get any ringback and when i answered the call there was no RTP

Ayodeji Okanlawon · ‎05-29-2012

first of all, I still believe you are better off with sip trunk from CUCM. I am sure we can resolve issues with ringback. Do you have ANN in your MRG? You need Annunciator to play ring back on SIP trunks..

Ok, What is the region setting used between the ip phone and the h323 gateway? Is it G729?

Can you pull of cucm traces? and attach via text file..Your end point for some reason cant do the G729 advertised by your telco. Thats why in the ACK sent no codec is selected..

Please rate all useful posts

rynard.coetzee · ‎05-29-2012

Yes i have Annunciator in MRGL ,i can change the back to SIP trunk ,just did the H323 as a test. Region is set to G729. I will pull the CUCM traces quick

rynard.coetzee · ‎05-29-2012

Ok for now i have attached the debug voice ccapi inout as you requested earlier ,i have also changed the routing back to SIP end to end ,when i dial the number i get ringback and the device that i call rings ,when i answer on the device it drops the call ,but the cisco phone still plays ringback.

Ayodeji Okanlawon · ‎05-29-2012

I am seeing a disconnect cause of 65. and the disconnect is coming from your side again..Please send me cucm trace...if you can. To resolve issues like this we need to look at cucm traces

Now that you have changed the setup, this debug does not help much..If you can send debug ccsip messages with cum trace that will be great

Please rate all useful posts

rynard.coetzee · ‎05-30-2012

I have attached the CUCM trace for the call ,as far as i can see CUCM sends the invite and then receives the Ringing message from Provider ,but then that`s it ,it never receives any OK message when i answer the call.

rynard.coetzee · ‎05-30-2012

I am also attaching the output of a debig ccsip all that i did

rynard.coetzee · ‎05-30-2012

Thanks for the help ,i managed to get the issue resolved ,Problem was that my incoming dial-peer from CUCM was set to use G729r8 and my outgoing SIP dial-peer was set to use G729br8 ,so the router was trying to transcode ,don`t know how i missed this. I gave you 5 stars .

Thanks for the help