Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

SIP trunk to provider dropping calls

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 ?

Everyone's tags (6)
1 ACCEPTED SOLUTION

Accepted Solutions
VIP Super Bronze

Re: SIP trunk to provider dropping calls

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 "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
16 REPLIES
VIP Super Bronze

Re: SIP trunk to provider dropping calls

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 "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

SIP trunk to provider dropping calls

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

VIP Super Bronze

Re: SIP trunk to provider dropping calls

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 "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
VIP Super Bronze

Re: SIP trunk to provider dropping calls

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 "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

SIP trunk to provider dropping calls

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

VIP Super Bronze

SIP trunk to provider dropping calls

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 "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

SIP trunk to provider dropping calls

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

VIP Super Bronze

SIP trunk to provider dropping calls

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 "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

SIP trunk to provider dropping calls

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

New Member

Re: SIP trunk to provider dropping calls

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.

VIP Super Bronze

Re: SIP trunk to provider dropping calls

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 "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Re: SIP trunk to provider dropping calls

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.

New Member

Re: SIP trunk to provider dropping calls

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

New Member

Re: SIP trunk to provider dropping calls

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

VIP Super Bronze

SIP trunk to provider dropping calls

Rynard,

Thanks for the nice rating and I am glad it worked. I knew it was a codec problem because cause 65 usually implies mismatch in different variations of same codec.. And that was why you couldnot send an ACK with SDP.

For purpose of other users who may experience this problem, I suggest you mark this as answered. So when people are looking through the forum they can see that this thread is answered..

You can mark this time line in the thread.. Its up to you though. I just find it useful when I am looking through threads to see answered or not..

29-May-2012 08:24 (in response to rynard.coetzee)

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
VIP Super Bronze

Re: SIP trunk to provider dropping calls

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 "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
10424
Views
21
Helpful
16
Replies
CreatePlease login to create content