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
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>
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 _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
This is something I've been wondering about as well. What's the reason for the channel being parked? Cheers -- Dave
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> 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 _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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> wrote:
This is something I've been wondering about as well. What's the reason for the channel being parked?
Cheers --
Dave
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> 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 _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400 _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
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
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> wrote: This is something I've been wondering about as well. What's the reason for the channel being parked?
Cheers --
Dave
> 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> > 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 > _______________________________________________ > Freeswitch-users mailing list > Freeswitch-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org > > > > > -- > Anthony Minessale II > > FreeSWITCH http://www.freeswitch.org/ > ClueCon http://www.cluecon.com/ > > AIM: anthm > MSN:anthony_minessale@hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888@conference.freeswitch.org > iax:guest@conference.freeswitch.org/888 > googletalk:conf+888@conference.freeswitch.org > pstn:213-799-1400 > _______________________________________________ > Freeswitch-users mailing list > Freeswitch-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
"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:
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
-- View this message in context: http://www.nabble.com/mod_event_socket-183-early-media-tp23503263p23516585.h... Sent from the Freeswitch-users mailing list archive at Nabble.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ó:
"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:
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
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> wrote:
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ó:
"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:
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
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
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ó:
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> wrote: 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ó: > "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: > > > > 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 > > > > >
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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> wrote:
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ó:
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> wrote: 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ó: > "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: > > > > 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 > > > > >
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400 _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
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>
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> wrote:
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ó:
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> wrote: 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ó: > "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: > > > > 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 > > > > >
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400 _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.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>wrote:
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>
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> wrote:
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ó:
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> wrote: 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ó: > "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: > > > > 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 > > > > >
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com<MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org<sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400 _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (7)
-
Anthony Minessale
-
David Knell
-
ibrahim tunali
-
İbrahim TUNALI
-
Michael Collins
-
Mikael Aleksander Bjerkeland
-
Mikael Bjerkeland