cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2455
Views
10
Helpful
5
Replies

SIP TRansfer across CUBE one way audio

rynard.coetzee
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

Hello,

Can you remove "midcall-signaling passthru" and configure "midcall-signaling passthru media-change" under sip and check?

View solution in original post

5 Replies 5

MOHIT SINGH
Level 1
Level 1

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.

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

Hello,

Can you remove "midcall-signaling passthru" and configure "midcall-signaling passthru media-change" under sip and check?

Hi Mohit

,thanks that worked ,any info what the difference is between the two ? And why this is now working ?

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