ā05-29-2012 06:21 AM - edited ā03-16-2019 11:23 AM
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 ?
Solved! Go to Solution.
ā05-30-2012 01:30 AM
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]
ā05-29-2012 06:35 AM
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: 027726157245>27112057000>
*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: 027726157245>27112057000>
We need to look at your config to have an idea of why this is happening...
ā05-29-2012 06:39 AM
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
ā05-29-2012 06:42 AM
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.
ā05-29-2012 06:40 AM
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
ā05-29-2012 06:45 AM
I will have to do a debug ccapi after hours as that GW is quite busy during OH .
ā05-29-2012 06:52 AM
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?
ā05-29-2012 07:03 AM
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
ā05-29-2012 07:24 AM
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..
ā05-29-2012 08:41 AM
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
ā05-29-2012 08:49 AM
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.
ā05-29-2012 10:43 AM
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
ā05-30-2012 12:15 AM
ā05-30-2012 12:18 AM
ā05-30-2012 12:34 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide