04-21-2016 05:09 AM - edited 03-18-2019 11:57 AM
Hi All
I have a strange issue that i would like some help with please
Call flow :
Mediant 800 Transcoder -- SIP -- Freeswitch --- SIP --- CUBE --- SIP --- CUCM
Incoming call to cisco phone works fine and i can answer and have 2 way audio ,when i press transfer called party is placed on hold fine ,then phone 2nd cisco phone and when answered there and call is transferred there is only audio in 1 direction ,outgoing from Cisco phone.
Strange issue i am seeing in traces are that initial call leg gets established between Freeswitch and CUBE but when CUBE sends invite from newly established call ,it is sending it directly to Transcoder. In the Orginal INVITE the only reference i can see to the Transcoder IP is in FROM field and
P-Asserted-Identity field as per below :
From: "+27827016165" <sip:27827016165@197.221.111.1>;tag=1c1543675873 --- 197.221.111.1 is transcoder ip
To: <sip:27874401900@197.221.113.17> --- 197.221.113.17 is CUBE Ip
Call-ID: 1543625752235201073934@197.221.113.50
CSeq: 1 INVITE
Contact: <sip:mod_sofia@197.221.113.50:5060>
Supported: timer,replaces,path
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
User-Agent: Mediant 800B/v.6.80A.285
Privacy: none
P-Asserted-Identity: "+27827016165" <sip:27827016165@197.221.111.1>
Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Length: 383
X-FS-Support: update_display,send_info
v=0
o=FreeSWITCH 1542808898 1542808807 IN IP4 197.221.113.50
s=FreeSWITCH
c=IN IP4 197.221.113.50
t=0 0
m=audio 6070 RTP/AVP 18 4 8 118 100
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=rtpmap:8 PCMA/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=rtpmap:118 PCMA/8000
a=gpmd:118 vbd=yes
a=gpmd:110 vbd=yes
a=pmft: T38
Can anyone shed some light on this ?
Attached is the debug from CUBE
Solved! Go to Solution.
04-21-2016 06:18 AM
Hello,
Can you remove "midcall-signaling passthru" and configure "midcall-signaling passthru media-change" under sip and check?
04-21-2016 05:47 AM
Hello Rynard,
The ReInvite is sent to "mod_sofia@197.221.113.50" by CUBE because it was received in Contact header of the first Invite.
Contact: <sip:mod_sofia@197.221.113.50:5060>
Do you have "midcall-signaling passthru media-change" configured under "voice service voip" in CUBE? If not can you configure it and test.
Just FYI.. there is no DTMF configuration under dial peer to CUCM. The DTMF payload used by Mediant is 100. Cisco uses by default 101 for rtp-nte.
04-21-2016 06:12 AM
Hi
I have that configured ,please see below :
voice service voip
address-hiding
dtmf-interworking rtp-nte
mode border-element license capacity 20
allow-connections sip to sip
redirect ip2ip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
bind control source-interface Loopback0
bind media source-interface Loopback0
header-passing
no update-callerid
early-offer forced
midcall-signaling passthru
sip-profiles 1
04-21-2016 06:18 AM
Hello,
Can you remove "midcall-signaling passthru" and configure "midcall-signaling passthru media-change" under sip and check?
04-21-2016 07:04 AM
Hi Mohit
,thanks that worked ,any info what the difference is between the two ? And why this is now working ?
04-21-2016 07:13 AM
Hi,
This command will consume the ReInvite received from CUCM for transfer so no ReInvite will be sent to Mediant. This stops renogotiating of media again. ReInvite will only be sent to Mediant for a call if it changing from audio to fax/video. Check below document
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-midcall-reinvite.html
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