VoIP Mailing List Archives

[ibrahim.tunali at comt...]

Hi,
I am trying to build a SBC but a kind of different described on wiki.

I immediately send incoming leg A to a socket app and connect bridge with my socket python application. I will handle all business logic on python side.

My dialplan is so simple;

    <extension name="SBCSocket">
        <condition field="destination_number" expression="^1000$">
        <action application="socket" data="127.0.0.1:1905 async full"/>
        </condition>
    </extension>

Freeswitch send calls to parking and 183 early media through mod_sofia. This is unacceptable on my SBC scenario. Because I not receive 183 or 180 from leg B yet. I want to relay early media or ringing when I received from B leg

I realize this is not a bug. It is a feature but i need to know is this possible.

I would appreciate all suggestions and clues.

Regards,
ibrahim

[ibrahim.tunali at comt...]

Hi,
I am trying to build a SBC but a kind of different described on wiki.

I immediately send incoming leg A to a socket app and connect bridge with my socket python application. I will handle all business logic on python side.

My dialplan is so simple;

    <extension name="SBCSocket">
        <condition field="destination_number" expression="^1000$">
        <action application="socket" data="127.0.0.1:1905 async full"/>
        </condition>
    </extension>

Freeswitch send calls to parking and 183 early media through mod_sofia. This is unacceptable on my SBC scenario. Because I not receive 183 or 180 from leg B yet. I want to relay early media or ringing when I received from B leg

I realize this is not a bug. It is a feature but i need to know is this possible.

I would appreciate all suggestions and clues.

Regards,
ibrahim

[anthony.minessale at g...]

the socket app will always open early media, it's not currently possible to park a channel that does not have media, you could try to post a bounty for such a feature but it would have to be an elegant solution


2009/5/12 Ýbrahim TUNALI <ibrahim.tunali@comturk.com (ibrahim.tunali@comturk.com)>

[dave at 3c.co.uk]

This is something I've been wondering about as well. What's the reason
for the channel being parked?

Cheers --

Dave

[anthony.minessale at g...]

The park state is where the channel goes to be kept alive while you hold the socket.

The channel has to be in constant motion reading and writing audio or the audio would build up, akin to a gui app blocking and you can't press any of the buttons.

it may be possible for the park loop to tighten up when the call is not answered or in early media in advance
but it would not be able to do anything besides a few things like get and set variables until it was meda-enabled


On Tue, May 12, 2009 at 12:49 PM, David Knell <dave@3c.co.uk (dave@3c.co.uk)> wrote:

[dave at 3c.co.uk]

Gotcha - but in the case where the call hasn't yet got to a point where
there's a 183 been sent then I guess this wouldn't apply - there
shouldn't be any audio from the far end at this point, nor would the far
end be expecting any.

I'd suggest (and would volunteer to knock together a patch) adding a
'nopark' option to the socket command, which doesn't park the call - nor
would it change existing behaviour. Obviously, in a situation like that
outlined by Ibrahim where the socket app handles all aspects of the
call, then it'll need to make sure that it signals ringing, answer or
whatever to make the call state flow work.

--Dave

[ibrahim.tunali at comt...]

"nopark" option would be great. FS sends "100 trying" while opening socket
and leg A waits other responses from socket. If I send pre-answer command it
reply via 183 early media and activate RTP path.

Regards,
ibrahim


David Knell wrote:

[mikael at bjerkeland.com]

I've been looking for something like this as well, to make the outbound
event socket behave more like FastAGI and handle the logic.


El mié, 13-05-2009 a las 00:12 -0700, ibrahim tunali escribió:

[anthony.minessale at g...]

you *need* park because you have to have somewhere to anchor the call to and the park function is the routine
that actually parses all the DTMF and the commands you send the channel with sendmsg etc.

I would have to look into refactoring it so when there is no media on the channel, it would sleep in place
of reading audio but if you send it any instruction that required media like playback etc it would still instantly send
a 183.

Don't forget we are a b2bua here so proxying calls is only smoke and mirrors for us.

Just as if you put a playback "please_wait.wav" before bridge, when you try to use a media enabled app
it will automatically generate a 183 to establish early media to make it possible.

I'll see what I can do, it may be difficult to avoid regressions, don't forget my wishlist if i pull it off




On Wed, May 13, 2009 at 2:30 AM, Mikael Aleksander Bjerkeland <mikael@bjerkeland.com (mikael@bjerkeland.com)> wrote:

[mikael at bjerkeland.com]

If you could make it in such a way that 183 or early media is sent only
when media is really needed like you suggested yourself, it would work
in the exact way most users would expect.

A clarification of what happens if I do transfer or execute_extension on
a socket parked call would also be neat. I remember reading that a
transfer would alter the state of the call, but I haven't seen any
proper documentation for this claim.

Maybe if you're lucky Santa comes earlier this year.


El mié, 13-05-2009 a las 07:58 -0500, Anthony Minessale escribió:

[anthony.minessale at g...]

please test r13294 ASAP
i do not want to create any regressions that last more than a day.




On Wed, May 13, 2009 at 8:15 AM, Mikael Aleksander Bjerkeland <mikael@bjerkeland.com (mikael@bjerkeland.com)> wrote:

[mikael at bjerkeland.com]

Connection to "Action socket(localhost:8086 full)" works! No early media there. Scenarios tested:

* Just setting a few vars, then bridge attempt to a phone generates 180 ringing - as expected
* Answer, then playback answers the call and plays audio - as expected
* Playback sends 183 session progress and plays audio - as expected


Great work. No regressions seen in my scenario.



2009/5/13 Anthony Minessale <anthony.minessale@gmail.com (anthony.minessale@gmail.com)>

[msc at freeswitch.org]

Anthm's paypal link is conveniently located on the right side of the main FreeSWITCH page...

-MC

On Wed, May 13, 2009 at 1:30 PM, Mikael Bjerkeland <mikael@bjerkeland.com (mikael@bjerkeland.com)> wrote: