VoIP Mailing List Archives

[shiyanov at gmail.com]

Hello!

I got a problem with one way audio, symptoms are:
firstly play audio file to channel A (A is hears sound)
secondly bridge channel B with A (A doesn't hear B).

Environment:
- no NAT
- User Agents being used X-Lite, EyeBeam, SJphone - same result for all of them- no audio, Wireshark shows that there is no RTP-flow to A from FreeSwitch
- dialplan:
<extension name="playback_media_file">
    <condition field="destination_number" expression="playmedia">
      <action application="answer"/>
      <action application="playback" data="test.wav"/>
    </condition>
  </extension>

<extension name="Local_Extension_from_SP">
      <condition field="destination_number" expression="^([0-9]{2,9})$">
        <action application="set" data="dialed_extension=$1"/>
        <action application="export" data="dialed_extension=$1"/>
      </condition>
      <condition field="${sip_to_host}" expression="^([^.]*)\..*$">
        <action application="set" data="orgname=$1"/>
      </condition>
      <condition field="destination_number" expression="^${caller_id_number}$">
        <anti-action application="set" data="ringback=${us-ring}"/>
        <anti-action application="set" data="transfer_ringback=${us-ring}"/>
        <anti-action application="set" data="call_timeout=10"/>
        <anti-action application="set" data="hangup_after_bridge=true"/>
        <anti-action application="set" data="continue_on_fail=NORMAL_TEMPORARY_FAILURE,USER_BUSY,NO_ANSWER,TIMEOUT,NO_ROUTE_DESTINATION,USER_NOT_REGISTERED"/>
        <anti-action application="set" data="continue_on_fail=true"/>
        <anti-action application="db" data="insert/${domain_name}-call_return/${dialed_extension}/${caller_id_number}"/>
        <anti-action application="db" data="insert/${domain_name}-last_dial_ext/${dialed_extension}/${uuid}"/>
        <anti-action application="set" data="called_party_callgroup=${user_data(${dialed_extension}@${domain_name} var callgroup)}"/>
        <anti-action application="db" data="insert/${domain_name}-last_dial/${called_party_callgroup}/${uuid}"/>
        <anti-action application="bridge" data="user/${dialed_extension}@${domain_name}"/>
        <anti-action application="answer"/>
        <anti-action application="export" data="sip_h_X-SPFrom=&quote;${sip_from_user}&quote;&lt;${sip_from_uri}&gt;"/>
        <anti-action application="export" data="sip_h_X-SPTo=&lt;${sip_to_uri}&gt;"/>
        <anti-action application="export" data="sip_h_X-SPCallId=${sip_call_id}"/>
        <anti-action application="bridge" data="sofia/external/${orgname}send2voicemail@$${starpound_sip_app_server}"/>
      </condition>
    </extension>
- Call routing scheme:
user calls to FS, FS calls to my B2BUA which manage call with SIP 3pcc
Exact description what's going on is:
user A -> FS -(bridge)-> my B2BUA
Then my B2BUA transfers (using re-INVITE's), on behalf of user, call to extension "playback_media_file" . After a while B2BUA transfer (re-Inviting) user to extension "Local_Extension_from_SP". This should create a new call to user B. As a result - A doesn't hear B, but B- is OK.
On the contrary, if a call is routed (by B2BUA) to the "Local_Extension_from_SP" extension (ommiting "playback_media_file" ext) - everything is OK.


What I've tried:
- set parameter "inbound-proxy-media" to "true" in Sofia profile
- set parameter "disable_rtp_auto_adjust to "true" in Sofia profile
Nothing helps.


Any help or thoughts would be MUCH appreciated!
Artem

[shiyanov at gmail.com]

Updates:
1. One-way audio is in 95% tries. But how the rest 5% works??
2. Strange FS logging after the channels are bridged (user A talk to user B)


2009-06-26 02:16:07 [DEBUG] sofia.c:2728 sofia_handle_sip_i_state() Channel sofia/external/1005@192.168.147.1 (1005@192.168.147.1) entering state [ready]
2009-06-26 02:16:07 [DEBUG] sofia.c:2732 sofia_handle_sip_i_state() Remote SDP:
v=0
o=FreeSWITCH 3898736844884231 105343281763004076 IN IP4 192.168.147.130
s=FreeSWITCH
c=IN IP4 192.168.147.130
t=0 0
m=audio 31134 RTP/AVP 0 101 13
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=ptime:20
m=video 0 RTP/AVP 34
a=rtpmap:34 H263/90000

2009-06-26 02:16:07 [DEBUG] sofia.c:2728 sofia_handle_sip_i_state() Channel sofia/external/1000000000@192.168.147.130:5060 entering state [ready]
freeswitch@localhost.localdomain> 2009-06-26 02:17:09 [DEBUG] sofia.c:2728 sofia_handle_sip_i_state() Channel sofia/external/1005@uat.pbx.starpoundtech.net (1005@uat.pbx.starpoundtech.net) entering state [calling]
2009-06-26 02:17:09 [DEBUG] sofia.c:2728 sofia_handle_sip_i_state() Channel sofia/external/1005@uat.pbx.starpoundtech.net (1005@uat.pbx.starpoundtech.net) entering state [ready]
2009-06-26 02:17:09 [DEBUG] sofia.c:2732 sofia_handle_sip_i_state() Remote SDP:
v=0
o=- 1 3 IN IP4 192.168.147.1
s=CounterPath X-Lite 3.0
c=IN IP4 192.168.147.1
t=0 0
m=audio 47590 RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15


freeswitch@localhost.localdomain> show calls

API CALL [show(calls)] output:
created,created_epoch,function,caller_cid_name,caller_cid_num,caller_dest_num,caller_chan_name,caller_uuid,callee_cid_name,callee_cid_num,callee_dest_num,callee_chan_name,callee_uuid
2009-06-26 02:16:05,1245968165,switch_ivr_multi_threaded_bridge,1005,1005,inbound1000000000,sofia/external/1005@uat.pbx.starpoundtech.net (1005@uat.pbx.starpoundtech.net),4fa86434-b542-4066-99af-5924c78ddab7,1005,1005,1000000000@192.168.147.130:5060,sofia/external/1000000000@192.168.147.130:5060,73df8735-fee2-464d-aec0-fda886ba2cba
2009-06-26 02:16:07,1245968167,switch_ivr_multi_threaded_bridge,1005,1005,1001,sofia/external/1005@192.168.147.1 (1005@192.168.147.1),1c2c5f6d-669f-4432-ad04-35a64dbc8a14,1005,1005,sip:1001@192.168.147.1:5060;fs_nat=yes,sofia/doublenat5090/sip:1001@192.168.147.1:5060;fs_nat=yes,66895f68-70bf-410a-bff7-cda9549c102d

2 total.

freeswitch@localhost.localdomain> 2009-06-26 02:18:09 [DEBUG] sofia.c:2728 sofia_handle_sip_i_state() Channel sofia/external/1005@uat.pbx.starpoundtech.net (1005@uat.pbx.starpoundtech.net) entering state [calling]
2009-06-26 02:18:10 [DEBUG] sofia.c:2728 sofia_handle_sip_i_state() Channel sofia/external/1005@uat.pbx.starpoundtech.net (1005@uat.pbx.starpoundtech.net) entering state [ready]
2009-06-26 02:18:10 [DEBUG] sofia.c:2732 sofia_handle_sip_i_state() Remote SDP:
v=0
o=- 1 3 IN IP4 192.168.147.1
s=CounterPath X-Lite 3.0
c=IN IP4 192.168.147.1
t=0 0
m=audio 47590 RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

2009-06-26 02:19:07 [DEBUG] sofia.c:2728 sofia_handle_sip_i_state() Channel sofia/external/1005@uat.pbx.starpoundtech.net (1005@uat.pbx.starpoundtech.net) entering state [calling]
2009-06-26 02:19:08 [DEBUG] sofia.c:2728 sofia_handle_sip_i_state() Channel sofia/external/1005@uat.pbx.starpoundtech.net (1005@uat.pbx.starpoundtech.net) entering state [ready]
2009-06-26 02:19:08 [DEBUG] sofia.c:2732 sofia_handle_sip_i_state() Remote SDP:
v=0
o=- 1 3 IN IP4 192.168.147.1
s=CounterPath X-Lite 3.0
c=IN IP4 192.168.147.1
t=0 0
m=audio 47590 RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15




Artem







On Fri, Jun 26, 2009 at 9:25 PM, Artem Shiyanov <shiyanov@gmail.com (shiyanov@gmail.com)> wrote:

[brian at freeswitch.org]

Can you try svn trunk... I know the remote FreeSWITCH isn't on trunk
also... due to the lines below.

/b

On Jun 26, 2009, at 12:59 PM, Artem Shiyanov wrote:

[shiyanov at gmail.com]

I've tried with the snapshot (06.26.2009) - and situation had become even worse - now both agents hear nothing..
Maybe problem is in my sip_profiles?
Here they are:
http://pastebin.freeswitch.org/pastebin.php?dl=9510
http://pastebin.freeswitch.org/pastebin.php?dl=9511



On Fri, Jun 26, 2009 at 10:03 PM, Brian West <brian@freeswitch.org (brian@freeswitch.org)> wrote:

[brian at freeswitch.org]

Now you'll need to outline step by step what you're doing to reproduce this problem.

/b

On Jun 29, 2009, at 10:41 AM, Artem Shiyanov wrote:

[shiyanov at gmail.com]

Update again:
FS debug logs of the problematic part
http://pastebin.freeswitch.org/pastebin.php?dl=9512

Artem





On Mon, Jun 29, 2009 at 7:07 PM, Artem Shiyanov <shiyanov@gmail.com (shiyanov@gmail.com)> wrote: