multiple leg and multiple rtp
hello is it possible to bridge multiple b-legs and provide all audio (progress) until there is an answer on one channel? thanks guys David
Are you asking if you can mux all of the progress audio from multiple b-legs? if so, no, and why would you want to? Mike On Jan 13, 2010, at 6:15 AM, David Villasmil wrote:
hello
is it possible to bridge multiple b-legs and provide all audio (progress) until there is an answer on one channel?
Thanks for answering, Well, imagine I have a content provider which will deliver custom ringbacks via SIP INVITES, they point would be to receive A-leg then bridge to 2 B-legs and deliver both incoming rops to A-side. Another option is to fork the call with bridge, the bad thing is that as soon as FS receives progress/audio from 1 leg, FS discards the other one, not good for me :) Thanks, and I hope you can enlighten me! David On Wed, Jan 13, 2010 at 6:21 PM, Michael Jerris <mike@jerris.com> wrote:
Are you asking if you can mux all of the progress audio from multiple b-legs? if so, no, and why would you want to?
Mike
On Jan 13, 2010, at 6:15 AM, David Villasmil wrote:
hello
is it possible to bridge multiple b-legs and provide all audio (progress) until there is an answer on one channel?
_______________________________________________ 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
Muxing 2 ringtones together would result in complete nonsense, especially in the case of custom ringback. How could this ever be usable? Mike On Jan 13, 2010, at 3:20 PM, David Villasmil wrote:
Thanks for answering,
Well, imagine I have a content provider which will deliver custom ringbacks via SIP INVITES, they point would be to receive A-leg then bridge to 2 B-legs and deliver both incoming rops to A-side. Another option is to fork the call with bridge, the bad thing is that as soon as FS receives progress/audio from 1 leg, FS discards the other one, not good for me :)
Thanks, and I hope you can enlighten me!
David
On Wed, Jan 13, 2010 at 6:21 PM, Michael Jerris <mike@jerris.com> wrote: Are you asking if you can mux all of the progress audio from multiple b-legs? if so, no, and why would you want to?
Mike
On Jan 13, 2010, at 6:15 AM, David Villasmil wrote:
hello
is it possible to bridge multiple b-legs and provide all audio (progress) until there is an answer on one channel?
_______________________________________________ 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
On Wed, Jan 13, 2010 at 8:43 PM, Michael Jerris <mike@jerris.com> wrote:
Muxing 2 ringtones together would result in complete nonsense, especially in the case of custom ringback. How could this ever be usable?
It sounds like he wants to mux two audio streams so he can have the normal ringback tone overlaid on a novelty ringback tone so as not to confuse the caller (I understand this is quite a normal way of doing such things) The easiest way to do this (and the way I do it) is to record a normal ringback tone then use sox to combine the custom ringback with the normal one and use the resulting file as your ringback. You get fine control over the timing and volume this way too.
MIke, This is done on a daily basis by i.e. mobile companies, you dial a customer number and you hear some music whilst hearing the ringing at the same time. If it can not be done by muxing both rtps, can it be done the other way, then?: (Another option is to fork the call with bridge, the bad thing is that as soon as FS receives progress/audio from 1 leg, FS discards the other one, not good for me ) Thanks david On Wed, Jan 13, 2010 at 9:43 PM, Michael Jerris <mike@jerris.com> wrote:
Muxing 2 ringtones together would result in complete nonsense, especially in the case of custom ringback. How could this ever be usable?
Mike
On Jan 13, 2010, at 3:20 PM, David Villasmil wrote:
Thanks for answering,
Well, imagine I have a content provider which will deliver custom ringbacks via SIP INVITES, they point would be to receive A-leg then bridge to 2 B-legs and deliver both incoming rops to A-side. Another option is to fork the call with bridge, the bad thing is that as soon as FS receives progress/audio from 1 leg, FS discards the other one, not good for me :)
Thanks, and I hope you can enlighten me!
David
On Wed, Jan 13, 2010 at 6:21 PM, Michael Jerris <mike@jerris.com> wrote:
Are you asking if you can mux all of the progress audio from multiple b-legs? if so, no, and why would you want to?
Mike
On Jan 13, 2010, at 6:15 AM, David Villasmil wrote:
hello
is it possible to bridge multiple b-legs and provide all audio (progress) until there is an answer on one channel?
_______________________________________________ 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
_______________________________________________ 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
It can not be done currently and I don't expect this to ever be done. The specs says the first target out of all invites to provide media wins and the others are canceled. That is why it behaves the way it does. You can ignore_early_media=true and set ringback=blah.wav if you wish to provide caller ringback. /b On Jan 13, 2010, at 8:10 PM, David Villasmil wrote:
MIke,
This is done on a daily basis by i.e. mobile companies, you dial a customer number and you hear some music whilst hearing the ringing at the same time.
If it can not be done by muxing both rtps, can it be done the other way, then?: (Another option is to fork the call with bridge, the bad thing is that as soon as FS receives progress/audio from 1 leg, FS discards the other one, not good for me )
Thanks
david
Well, the question is - what is "media"? To me media is what is returned by "200 OK" response to INVITE. 18X provisional responses are NOT media, they are early media indications (well, even with RTP stream inside), which shall be sent back to the caller, but should NOT be accounted in the call processing. Early media is too early to be accounted. Only responses with SIP code 200 or more matter. On Wednesday 13 January 2010, Brian West wrote:
It can not be done currently and I don't expect this to ever be done. The specs says the first target out of all invites to provide media wins and the others are canceled. That is why it behaves the way it does.
You can ignore_early_media=true and set ringback=blah.wav if you wish to provide caller ringback.
/b
On Jan 13, 2010, at 8:10 PM, David Villasmil wrote:
MIke,
This is done on a daily basis by i.e. mobile companies, you dial a customer number and you hear some music whilst hearing the ringing at the same time.
If it can not be done by muxing both rtps, can it be done the other way, then?: (Another option is to fork the call with bridge, the bad thing is that as soon as FS receives progress/audio from 1 leg, FS discards the other one, not good for me )
Thanks
david
_______________________________________________ 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
By all accounts its still Media and the first one to provide it in a forked dial is to be connected to the channel of the calling party even if its early... the call answer time is not started till the 200 is received. I'm not talking about billing or answered time either.. i'm talking pure early media and how it is to be handled in FreeSWITCH. That my friend is in the specs to behave like that. /b On Jan 13, 2010, at 9:05 PM, Sergey Okhapkin wrote:
Well, the question is - what is "media"? To me media is what is returned by "200 OK" response to INVITE. 18X provisional responses are NOT media, they are early media indications (well, even with RTP stream inside), which shall be sent back to the caller, but should NOT be accounted in the call processing. Early media is too early to be accounted. Only responses with SIP code 200 or more matter.
If you wish FreeSWITCH to be well adopted by the community, then FS should follow the real world "rules" but not specs... Don't you agree that 99% of SIP servers are set up to interconnect with "buggy" PSTN and should follow PSTN rules, but not SIP specs? Some background - I did run asterisk for years, but switched to FS recently because of critical asterisk problems with SIP handling when asterisk is not in the media path. I spend a lot of time porting the billing system to FS. And I did it. What I got? Critical problems with FS early media handling. Hopefully I can switch back to asterisk if FS problems with early media will begin to draw customers away. On Wednesday 13 January 2010, Brian West wrote:
By all accounts its still Media and the first one to provide it in a forked dial is to be connected to the channel of the calling party even if its early... the call answer time is not started till the 200 is received.
I'm not talking about billing or answered time either.. i'm talking pure early media and how it is to be handled in FreeSWITCH.
That my friend is in the specs to behave like that.
/b
On Jan 13, 2010, at 9:05 PM, Sergey Okhapkin wrote:
Well, the question is - what is "media"? To me media is what is returned by "200 OK" response to INVITE. 18X provisional responses are NOT media, they are early media indications (well, even with RTP stream inside), which shall be sent back to the caller, but should NOT be accounted in the call processing. Early media is too early to be accounted. Only responses with SIP code 200 or more matter.
_______________________________________________ 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
Can you elaborate on these "Critical" issues you seem to be having? Why aren't you opening a jira for them if they are that critical to your needs? /b On Jan 13, 2010, at 9:29 PM, Sergey Okhapkin wrote:
If you wish FreeSWITCH to be well adopted by the community, then FS should follow the real world "rules" but not specs...
Don't you agree that 99% of SIP servers are set up to interconnect with "buggy" PSTN and should follow PSTN rules, but not SIP specs?
Some background - I did run asterisk for years, but switched to FS recently because of critical asterisk problems with SIP handling when asterisk is not in the media path. I spend a lot of time porting the billing system to FS. And I did it. What I got? Critical problems with FS early media handling. Hopefully I can switch back to asterisk if FS problems with early media will begin to draw customers away.
Critical issues are when SIP error come after 18X provisional response. - if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513). - if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway ( http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/024354.h... ) I didn't track down yet why this happens looking at FS sources. Why I didn't open a bug on jira? Because FS behaves according to the design and specs :-) But not according to real world requirements... On Wednesday 13 January 2010, Brian West wrote:
Can you elaborate on these "Critical" issues you seem to be having? Why aren't you opening a jira for them if they are that critical to your needs?
/b
On Jan 13, 2010, at 9:29 PM, Sergey Okhapkin wrote:
If you wish FreeSWITCH to be well adopted by the community, then FS should follow the real world "rules" but not specs...
Don't you agree that 99% of SIP servers are set up to interconnect with "buggy" PSTN and should follow PSTN rules, but not SIP specs?
Some background - I did run asterisk for years, but switched to FS recently because of critical asterisk problems with SIP handling when asterisk is not in the media path. I spend a lot of time porting the billing system to FS. And I did it. What I got? Critical problems with FS early media handling. Hopefully I can switch back to asterisk if FS problems with early media will begin to draw customers away.
_______________________________________________ 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
This is exactly why you open a jira. But we have zero control over the far end sending a 18X then an error. That is NOT something we can fix. As for the others I suspect they have been fixed... what Rev are you running? /b On Jan 13, 2010, at 10:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513). - if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway ( http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/024354.h... ) I didn't track down yet why this happens looking at FS sources.
Why I didn't open a bug on jira? Because FS behaves according to the design and specs :-) But not according to real world requirements...
I run FreeSWITCH Version 1.0.5pre10 (16012M), sorry but I don't feel comfortable running SVN trunk on production servers... Perhaps because of my experience with asterisk. Neither version after 1.4.18 did work OK to me. On Wednesday 13 January 2010, Brian West wrote:
This is exactly why you open a jira. But we have zero control over the far end sending a 18X then an error. That is NOT something we can fix. As for the others I suspect they have been fixed... what Rev are you running?
/b
On Jan 13, 2010, at 10:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513). - if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway ( http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/02435 4.html ) I didn't track down yet why this happens looking at FS sources.
Why I didn't open a bug on jira? Because FS behaves according to the design and specs :-) But not according to real world requirements...
You already are running on trunk. Mike On Jan 13, 2010, at 11:26 PM, Sergey Okhapkin wrote:
I run FreeSWITCH Version 1.0.5pre10 (16012M), sorry but I don't feel comfortable running SVN trunk on production servers... Perhaps because of my experience with asterisk. Neither version after 1.4.18 did work OK to me.
On Wednesday 13 January 2010, Brian West wrote:
This is exactly why you open a jira. But we have zero control over the far end sending a 18X then an error. That is NOT something we can fix. As for the others I suspect they have been fixed... what Rev are you running?
/b
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and hangup_after_bridge channel vars, perhaps ignore_early_media as well
- if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway ( http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/024354.h... ) I didn't track down yet why this happens looking at FS sources.
see response on that thread
Why I didn't open a bug on jira? Because FS behaves according to the design and specs :-) But not according to real world requirements...
Really, people are trying to help you and your going to be snarky in response?
On Wednesday 13 January 2010, Brian West wrote:
Can you elaborate on these "Critical" issues you seem to be having? Why aren't you opening a jira for them if they are that critical to your needs?
Mike
Case 1 (bypass_media is off) is already on jira, http://jira.freeswitch.org/browse/FSCORE-257 , I will prepare a test installation with latest trunk to reproduce case 2, when bypass_media=true and 10 seconds delay happens when 18X and then error are received on leg b. On Wednesday 13 January 2010, Michael Jerris wrote:
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and hangup_after_bridge channel vars, perhaps ignore_early_media as well
- if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway ( http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/02435 4.html ) I didn't track down yet why this happens looking at FS sources.
see response on that thread
Why I didn't open a bug on jira? Because FS behaves according to the design and specs :-) But not according to real world requirements...
Really, people are trying to help you and your going to be snarky in response?
On Wednesday 13 January 2010, Brian West wrote:
Can you elaborate on these "Critical" issues you seem to be having? Why aren't you opening a jira for them if they are that critical to your needs?
Mike
_______________________________________________ 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 first question is why are you using Proxy Media? Secondly I'm almost positive that issue was resolved. Thirdly 1.0.5pre10 was just an SVN snapshot! We have since fixed a multitude of tiny issues here and there since that time one being a bug related to proxy media mode. Thanks, /b On Jan 14, 2010, at 6:19 AM, Sergey Okhapkin wrote:
Case 1 (bypass_media is off) is already on jira, http://jira.freeswitch.org/browse/FSCORE-257 , I will prepare a test installation with latest trunk to reproduce case 2, when bypass_media=true and 10 seconds delay happens when 18X and then error are received on leg b.
Sergey, The bug you reference was closed because proxy_media mode by design send's the B leg's codec to the A LEG so if there is a failure condition there is no easy graceful way to back out and try another call. I will try to make it possible if yo post a bounty, I estimate a minimum of $1000USD in consulting time. The other one I might look at once you have apologized. I can probably add some code to make the bridge exit without terminating the A leg even when hangup_after_bridge=true in the case where the the B leg is not answered but right now I am sort of annoyed with your attitude in this thread. On Thu, Jan 14, 2010 at 6:19 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
Case 1 (bypass_media is off) is already on jira, http://jira.freeswitch.org/browse/FSCORE-257 , I will prepare a test installation with latest trunk to reproduce case 2, when bypass_media=true and 10 seconds delay happens when 18X and then error are received on leg b.
On Wednesday 13 January 2010, Michael Jerris wrote:
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and hangup_after_bridge channel vars, perhaps ignore_early_media as well
- if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway (
http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/02435
4.html ) I didn't track down yet why this happens looking at FS sources.
see response on that thread
Why I didn't open a bug on jira? Because FS behaves according to the design and specs :-) But not according to real world requirements...
Really, people are trying to help you and your going to be snarky in response?
On Wednesday 13 January 2010, Brian West wrote:
Can you elaborate on these "Critical" issues you seem to be having? Why aren't you opening a jira for them if they are that critical to your needs?
Mike
_______________________________________________ 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/ Twitter: http://twitter.com/FreeSWITCH_wire 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:+19193869900
David, Your request is somewhat challenging because we have to make sure FreeSWITCH is agnostic in protocols and that aside, we also have a very complicated and feature-rich originate API that does not currently support sending audio from one leg to the A leg while it's trying to call 10 other B legs. Please try to understand that this request is a very special side case and we would have to do many hours of work to make it possible. I am not sure if you are simply asking if its possible or if you want us to implement it for you but I am afraid it would fall under commercial support to undertake that unique of a feature that only helps a very small percentage of our user base considering all the work we already have to do every day. On Thu, Jan 14, 2010 at 10:22 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
Sergey,
The bug you reference was closed because proxy_media mode by design send's the B leg's codec to the A LEG so if there is a failure condition there is no easy graceful way to back out and try another call. I will try to make it possible if yo post a bounty, I estimate a minimum of $1000USD in consulting time.
The other one I might look at once you have apologized.
I can probably add some code to make the bridge exit without terminating the A leg even when hangup_after_bridge=true in the case where the the B leg is not answered but right now I am sort of annoyed with your attitude in this thread.
On Thu, Jan 14, 2010 at 6:19 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org
wrote:
Case 1 (bypass_media is off) is already on jira, http://jira.freeswitch.org/browse/FSCORE-257 , I will prepare a test installation with latest trunk to reproduce case 2, when bypass_media=true and 10 seconds delay happens when 18X and then error are received on leg b.
On Wednesday 13 January 2010, Michael Jerris wrote:
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and hangup_after_bridge channel vars, perhaps ignore_early_media as well
- if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway (
http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/02435
4.html ) I didn't track down yet why this happens looking at FS sources.
see response on that thread
Why I didn't open a bug on jira? Because FS behaves according to the design and specs :-) But not according to real world requirements...
Really, people are trying to help you and your going to be snarky in response?
On Wednesday 13 January 2010, Brian West wrote:
Can you elaborate on these "Critical" issues you seem to be having? Why aren't you opening a jira for them if they are that critical to your needs?
Mike
_______________________________________________ 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/ Twitter: http://twitter.com/FreeSWITCH_wire
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:+19193869900
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire 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:+19193869900
Anthony, Thanks. I understand it's complicated. Another option is to be able to configure whether or not to discard all other B-legs on receiving media but on receiving an final code like 200. This way we will still get the first media that arrived but provide an answer on the actual channel that provided the 200. My request comes from 2 sides, one commercial and the other personal. For the commercial I just need to now whether it is possible by some tweaking so the functionality can be offered. The other, I've been involved in FS as a user from the very beginning (although I was absent for some time), and I'd like to help in the development of the project by letting the community know what's out there commercially speaking. Hope you can help. David On Thu, Jan 14, 2010 at 5:26 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
David,
Your request is somewhat challenging because we have to make sure FreeSWITCH is agnostic in protocols and that aside, we also have a very complicated and feature-rich originate API that does not currently support sending audio from one leg to the A leg while it's trying to call 10 other B legs. Please try to understand that this request is a very special side case and we would have to do many hours of work to make it possible. I am not sure if you are simply asking if its possible or if you want us to implement it for you but I am afraid it would fall under commercial support to undertake that unique of a feature that only helps a very small percentage of our user base considering all the work we already have to do every day.
On Thu, Jan 14, 2010 at 10:22 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
Sergey,
The bug you reference was closed because proxy_media mode by design send's the B leg's codec to the A LEG so if there is a failure condition there is no easy graceful way to back out and try another call. I will try to make it possible if yo post a bounty, I estimate a minimum of $1000USD in consulting time.
The other one I might look at once you have apologized.
I can probably add some code to make the bridge exit without terminating the A leg even when hangup_after_bridge=true in the case where the the B leg is not answered but right now I am sort of annoyed with your attitude in this thread.
On Thu, Jan 14, 2010 at 6:19 AM, Sergey Okhapkin < sos@sokhapkin.dyndns.org> wrote:
Case 1 (bypass_media is off) is already on jira, http://jira.freeswitch.org/browse/FSCORE-257 , I will prepare a test installation with latest trunk to reproduce case 2, when bypass_media=true and 10 seconds delay happens when 18X and then error are received on leg b.
On Wednesday 13 January 2010, Michael Jerris wrote:
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and hangup_after_bridge channel vars, perhaps ignore_early_media as well
- if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway (
http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/02435
4.html ) I didn't track down yet why this happens looking at FS sources.
see response on that thread
Why I didn't open a bug on jira? Because FS behaves according to the design and specs :-) But not according to real world requirements...
Really, people are trying to help you and your going to be snarky in response?
On Wednesday 13 January 2010, Brian West wrote:
Can you elaborate on these "Critical" issues you seem to be having? Why aren't you opening a jira for them if they are that critical to your needs?
Mike
_______________________________________________ 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/ Twitter: http://twitter.com/FreeSWITCH_wire
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:+19193869900
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
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:+19193869900
_______________________________________________ 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
David I already understood your request. Even what you consider a compromise is a lot of work. You really should post a bounty for something this exotic. On Thu, Jan 14, 2010 at 10:41 AM, David Villasmil < david.villasmil.work@gmail.com> wrote:
Anthony,
Thanks. I understand it's complicated. Another option is to be able to configure whether or not to discard all other B-legs on receiving media but on receiving an final code like 200. This way we will still get the first media that arrived but provide an answer on the actual channel that provided the 200.
My request comes from 2 sides, one commercial and the other personal. For the commercial I just need to now whether it is possible by some tweaking so the functionality can be offered.
The other, I've been involved in FS as a user from the very beginning (although I was absent for some time), and I'd like to help in the development of the project by letting the community know what's out there commercially speaking.
Hope you can help.
David
On Thu, Jan 14, 2010 at 5:26 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
David,
Your request is somewhat challenging because we have to make sure FreeSWITCH is agnostic in protocols and that aside, we also have a very complicated and feature-rich originate API that does not currently support sending audio from one leg to the A leg while it's trying to call 10 other B legs. Please try to understand that this request is a very special side case and we would have to do many hours of work to make it possible. I am not sure if you are simply asking if its possible or if you want us to implement it for you but I am afraid it would fall under commercial support to undertake that unique of a feature that only helps a very small percentage of our user base considering all the work we already have to do every day.
On Thu, Jan 14, 2010 at 10:22 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
Sergey,
The bug you reference was closed because proxy_media mode by design send's the B leg's codec to the A LEG so if there is a failure condition there is no easy graceful way to back out and try another call. I will try to make it possible if yo post a bounty, I estimate a minimum of $1000USD in consulting time.
The other one I might look at once you have apologized.
I can probably add some code to make the bridge exit without terminating the A leg even when hangup_after_bridge=true in the case where the the B leg is not answered but right now I am sort of annoyed with your attitude in this thread.
On Thu, Jan 14, 2010 at 6:19 AM, Sergey Okhapkin < sos@sokhapkin.dyndns.org> wrote:
Case 1 (bypass_media is off) is already on jira, http://jira.freeswitch.org/browse/FSCORE-257 , I will prepare a test installation with latest trunk to reproduce case 2, when bypass_media=true and 10 seconds delay happens when 18X and then error are received on leg b.
On Wednesday 13 January 2010, Michael Jerris wrote:
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and hangup_after_bridge channel vars, perhaps ignore_early_media as well
- if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway (
http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/02435
4.html ) I didn't track down yet why this happens looking at FS sources.
see response on that thread
Why I didn't open a bug on jira? Because FS behaves according to the design and specs :-) But not according to real world requirements...
Really, people are trying to help you and your going to be snarky in response?
On Wednesday 13 January 2010, Brian West wrote: > Can you elaborate on these "Critical" issues you seem to be having? Why > aren't you opening a jira for them if they are that critical to your > needs?
Mike
_______________________________________________ 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/ Twitter: http://twitter.com/FreeSWITCH_wire
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:+19193869900
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
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:+19193869900
_______________________________________________ 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/ Twitter: http://twitter.com/FreeSWITCH_wire 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:+19193869900
Anthony, I apology, I didn't expect you'll be annoyed. As for the issue, the issue is not in "proxy_media" setting, same happens when both "proxy_media" and "bypass_media" are not set. The code does explicit leg A hangup in switch_ivr_bridge.c, line 513. The condition there is "if leg A is up and leg A is not in answered state, then hangup leg A", this prevents dialplan to continue execution on early media bridge termination. Issue when "bypass_media=true" is completely different, I'll open the issue on jira. On Thursday 14 January 2010, Anthony Minessale wrote:
Sergey,
The bug you reference was closed because proxy_media mode by design send's the B leg's codec to the A LEG so if there is a failure condition there is no easy graceful way to back out and try another call. I will try to make it possible if yo post a bounty, I estimate a minimum of $1000USD in consulting time.
The other one I might look at once you have apologized.
I can probably add some code to make the bridge exit without terminating the A leg even when hangup_after_bridge=true in the case where the the B leg is not answered but right now I am sort of annoyed with your attitude in this thread.
On Thu, Jan 14, 2010 at 6:19 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Case 1 (bypass_media is off) is already on jira, http://jira.freeswitch.org/browse/FSCORE-257 , I will prepare a test installation with latest trunk to reproduce case 2, when bypass_media=true and 10 seconds delay happens when 18X and then error are received on leg b.
On Wednesday 13 January 2010, Michael Jerris wrote:
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and hangup_after_bridge channel vars, perhaps ignore_early_media as well
- if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway (
http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/02435
4.html ) I didn't track down yet why this happens looking at FS sources.
see response on that thread
Why I didn't open a bug on jira? Because FS behaves according to the design and specs :-) But not according to real world requirements...
Really, people are trying to help you and your going to be snarky in response?
On Wednesday 13 January 2010, Brian West wrote:
Can you elaborate on these "Critical" issues you seem to be having?
Why
aren't you opening a jira for them if they are that critical to your needs?
Mike
_______________________________________________ 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-user s 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
One way you could fix it is set "hangup_after_bridge=false" and then set "execute_on_answer=set\shangup_after_bridge=true". That will make it continue executing the dialplan atter a failure that came in after 183. Note that there is a side effect to this method, since audio was being relayed, you are forced to use the same codec on the 2nd carrier, best to tell them they are wrong failing a call after 183. Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca On 14-Jan-10, at 11:41 AM, Sergey Okhapkin wrote:
Anthony, I apology, I didn't expect you'll be annoyed. As for the issue, the issue is not in "proxy_media" setting, same happens when both "proxy_media" and "bypass_media" are not set. The code does explicit leg A hangup in switch_ivr_bridge.c, line 513. The condition there is "if leg A is up and leg A is not in answered state, then hangup leg A", this prevents dialplan to continue execution on early media bridge termination.
Issue when "bypass_media=true" is completely different, I'll open the issue on jira.
On Thursday 14 January 2010, Anthony Minessale wrote:
Sergey,
The bug you reference was closed because proxy_media mode by design send's the B leg's codec to the A LEG so if there is a failure condition there is no easy graceful way to back out and try another call. I will try to make it possible if yo post a bounty, I estimate a minimum of $1000USD in consulting time.
The other one I might look at once you have apologized.
I can probably add some code to make the bridge exit without terminating the A leg even when hangup_after_bridge=true in the case where the the B leg is not answered but right now I am sort of annoyed with your attitude in this thread.
On Thu, Jan 14, 2010 at 6:19 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Case 1 (bypass_media is off) is already on jira, http://jira.freeswitch.org/browse/FSCORE-257 , I will prepare a test installation with latest trunk to reproduce case 2, when bypass_media=true and 10 seconds delay happens when 18X and then error are received on leg b.
On Wednesday 13 January 2010, Michael Jerris wrote:
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and hangup_after_bridge channel vars, perhaps ignore_early_media as well
- if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway (
http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/02435
4.html ) I didn't track down yet why this happens looking at FS sources.
see response on that thread
Why I didn't open a bug on jira? Because FS behaves according to the design and specs :-) But not according to real world requirements...
Really, people are trying to help you and your going to be snarky in response?
On Wednesday 13 January 2010, Brian West wrote:
Can you elaborate on these "Critical" issues you seem to be having?
Why
aren't you opening a jira for them if they are that critical to your needs?
Mike
_______________________________________________ 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-user s 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
_______________________________________________ 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
"hangup_after_bridge=false" is the default setting. On Thursday 14 January 2010, Mathieu Rene wrote:
One way you could fix it is set "hangup_after_bridge=false" and then set "execute_on_answer=set\shangup_after_bridge=true". That will make it continue executing the dialplan atter a failure that came in after 183. Note that there is a side effect to this method, since audio was being relayed, you are forced to use the same codec on the 2nd carrier, best to tell them they are wrong failing a call after 183.
Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca
On 14-Jan-10, at 11:41 AM, Sergey Okhapkin wrote:
Anthony, I apology, I didn't expect you'll be annoyed. As for the issue, the issue is not in "proxy_media" setting, same happens when both "proxy_media" and "bypass_media" are not set. The code does explicit leg A hangup in switch_ivr_bridge.c, line 513. The condition there is "if leg A is up and leg A is not in answered state, then hangup leg A", this prevents dialplan to continue execution on early media bridge termination.
Issue when "bypass_media=true" is completely different, I'll open the issue on jira.
On Thursday 14 January 2010, Anthony Minessale wrote:
Sergey,
The bug you reference was closed because proxy_media mode by design send's the B leg's codec to the A LEG so if there is a failure condition there is no easy graceful way to back out and try another call. I will try to make it possible if yo post a bounty, I estimate a minimum of $1000USD in consulting time.
The other one I might look at once you have apologized.
I can probably add some code to make the bridge exit without terminating the A leg even when hangup_after_bridge=true in the case where the the B leg is not answered but right now I am sort of annoyed with your attitude in this thread.
On Thu, Jan 14, 2010 at 6:19 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Case 1 (bypass_media is off) is already on jira, http://jira.freeswitch.org/browse/FSCORE-257 , I will prepare a test installation with latest trunk to reproduce case 2, when bypass_media=true and 10 seconds delay happens when 18X and then error are received on leg b.
On Wednesday 13 January 2010, Michael Jerris wrote:
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and hangup_after_bridge channel vars, perhaps ignore_early_media as well
- if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway (
http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/024 35
4.html ) I didn't track down yet why this happens looking at FS sources.
see response on that thread
Why I didn't open a bug on jira? Because FS behaves according to the design and specs :-) But not according to real world requirements...
Really, people are trying to help you and your going to be snarky in response?
On Wednesday 13 January 2010, Brian West wrote: > Can you elaborate on these "Critical" issues you seem to be > having?
Why
> aren't you opening a jira for them if they are that critical to > your > needs?
Mike
_______________________________________________ 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-use r s 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-user s 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
_______________________________________________ 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
ok both methods work now. your jira was fixed in r16311 and the non bypass equivalent was fixed in the previous commit On Thu, Jan 14, 2010 at 11:00 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
"hangup_after_bridge=false" is the default setting.
On Thursday 14 January 2010, Mathieu Rene wrote:
One way you could fix it is set "hangup_after_bridge=false" and then set "execute_on_answer=set\shangup_after_bridge=true". That will make it continue executing the dialplan atter a failure that came in after 183. Note that there is a side effect to this method, since audio was being relayed, you are forced to use the same codec on the 2nd carrier, best to tell them they are wrong failing a call after 183.
Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca
On 14-Jan-10, at 11:41 AM, Sergey Okhapkin wrote:
Anthony, I apology, I didn't expect you'll be annoyed. As for the issue, the issue is not in "proxy_media" setting, same happens when both "proxy_media" and "bypass_media" are not set. The code does explicit leg A hangup in switch_ivr_bridge.c, line 513. The condition there is "if leg A is up and leg A is not in answered state, then hangup leg A", this prevents dialplan to continue execution on early media bridge termination.
Issue when "bypass_media=true" is completely different, I'll open the issue on jira.
On Thursday 14 January 2010, Anthony Minessale wrote:
Sergey,
The bug you reference was closed because proxy_media mode by design send's the B leg's codec to the A LEG so if there is a failure condition there is no easy graceful way to back out and try another call. I will try to make it possible if yo post a bounty, I estimate a minimum of $1000USD in consulting time.
The other one I might look at once you have apologized.
I can probably add some code to make the bridge exit without terminating the A leg even when hangup_after_bridge=true in the case where the the B leg is not answered but right now I am sort of annoyed with your attitude in this thread.
On Thu, Jan 14, 2010 at 6:19 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Case 1 (bypass_media is off) is already on jira, http://jira.freeswitch.org/browse/FSCORE-257 , I will prepare a test installation with latest trunk to reproduce case 2, when bypass_media=true and 10 seconds delay happens when 18X and then error are received on leg b.
On Wednesday 13 January 2010, Michael Jerris wrote:
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote: > Critical issues are when SIP error come after 18X provisional > response. > > - if bypass_media is false then dialplan stops and leg a is > explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and hangup_after_bridge channel vars, perhaps ignore_early_media as well
> - if bypass_media is true, then dialplan continue, but there is 10 > seconds delay before next bridge application sends INVITE to > gateway > (
http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/024
35
> 4.html ) I didn't track down yet why this happens looking at FS > sources.
see response on that thread
> Why I didn't open a bug on jira? Because FS behaves according to > the > design and specs :-) But not according to real world > requirements...
Really, people are trying to help you and your going to be snarky in response?
> On Wednesday 13 January 2010, Brian West wrote: >> Can you elaborate on these "Critical" issues you seem to be >> having?
Why
>> aren't you opening a jira for them if they are that critical to >> your >> needs?
Mike
_______________________________________________ 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-use r s 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-user s 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
_______________________________________________ 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/ Twitter: http://twitter.com/FreeSWITCH_wire 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:+19193869900
Dne 14.1.2010 17:47, Mathieu Rene napsal(a):
One way you could fix it is set "hangup_after_bridge=false" and then set "execute_on_answer=set\shangup_after_bridge=true". That will make it continue executing the dialplan atter a failure that came in after 183. Note that there is a side effect to this method, since audio was being relayed, you are forced to use the same codec on the 2nd carrier, best to tell them they are wrong failing a call after 183.
Mathieu Rene
Hello Mathieu, are you sure, that "failing call" after 183 is wrong? I don't think so, but may be I'm wrong, so could you, please, point me to the docs? BTW: I'm prety sure, that this behaviour is VERY common in EU. IMO nearly all big carriers in case of call failure (according to ETSI recommendations) send first call-progress with media ("The number your are calling is unavailable" etc.) and than reject call with proper "Q" reason. And I think it should be mapped to SIP like 183+SDP and than 4XX/5XX/6XX. Just my 2c :-) Best regards, kokoska.rokoska
Or try r16309, where Anthony fixed it so it doesnt hangup if the b-leg isnt answered yet :D Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca On 14-Jan-10, at 11:41 AM, Sergey Okhapkin wrote:
Anthony, I apology, I didn't expect you'll be annoyed. As for the issue, the issue is not in "proxy_media" setting, same happens when both "proxy_media" and "bypass_media" are not set. The code does explicit leg A hangup in switch_ivr_bridge.c, line 513. The condition there is "if leg A is up and leg A is not in answered state, then hangup leg A", this prevents dialplan to continue execution on early media bridge termination.
Issue when "bypass_media=true" is completely different, I'll open the issue on jira.
On Thursday 14 January 2010, Anthony Minessale wrote:
Sergey,
The bug you reference was closed because proxy_media mode by design send's the B leg's codec to the A LEG so if there is a failure condition there is no easy graceful way to back out and try another call. I will try to make it possible if yo post a bounty, I estimate a minimum of $1000USD in consulting time.
The other one I might look at once you have apologized.
I can probably add some code to make the bridge exit without terminating the A leg even when hangup_after_bridge=true in the case where the the B leg is not answered but right now I am sort of annoyed with your attitude in this thread.
On Thu, Jan 14, 2010 at 6:19 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Case 1 (bypass_media is off) is already on jira, http://jira.freeswitch.org/browse/FSCORE-257 , I will prepare a test installation with latest trunk to reproduce case 2, when bypass_media=true and 10 seconds delay happens when 18X and then error are received on leg b.
On Wednesday 13 January 2010, Michael Jerris wrote:
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and hangup_after_bridge channel vars, perhaps ignore_early_media as well
- if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway (
http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/02435
4.html ) I didn't track down yet why this happens looking at FS sources.
see response on that thread
Why I didn't open a bug on jira? Because FS behaves according to the design and specs :-) But not according to real world requirements...
Really, people are trying to help you and your going to be snarky in response?
On Wednesday 13 January 2010, Brian West wrote:
Can you elaborate on these "Critical" issues you seem to be having?
Why
aren't you opening a jira for them if they are that critical to your needs?
Mike
_______________________________________________ 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-user s 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
_______________________________________________ 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
r16310 Thank you for the apology. On Thu, Jan 14, 2010 at 10:41 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
Anthony, I apology, I didn't expect you'll be annoyed. As for the issue, the issue is not in "proxy_media" setting, same happens when both "proxy_media" and "bypass_media" are not set. The code does explicit leg A hangup in switch_ivr_bridge.c, line 513. The condition there is "if leg A is up and leg A is not in answered state, then hangup leg A", this prevents dialplan to continue execution on early media bridge termination.
Issue when "bypass_media=true" is completely different, I'll open the issue on jira.
On Thursday 14 January 2010, Anthony Minessale wrote:
Sergey,
The bug you reference was closed because proxy_media mode by design send's the B leg's codec to the A LEG so if there is a failure condition there is no easy graceful way to back out and try another call. I will try to make it possible if yo post a bounty, I estimate a minimum of $1000USD in consulting time.
The other one I might look at once you have apologized.
I can probably add some code to make the bridge exit without terminating the A leg even when hangup_after_bridge=true in the case where the the B leg is not answered but right now I am sort of annoyed with your attitude in this thread.
On Thu, Jan 14, 2010 at 6:19 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Case 1 (bypass_media is off) is already on jira, http://jira.freeswitch.org/browse/FSCORE-257 , I will prepare a test installation with latest trunk to reproduce case 2, when bypass_media=true and 10 seconds delay happens when 18X and then error are received on leg b.
On Wednesday 13 January 2010, Michael Jerris wrote:
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and hangup_after_bridge channel vars, perhaps ignore_early_media as well
- if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway (
http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/02435
4.html ) I didn't track down yet why this happens looking at FS sources.
see response on that thread
Why I didn't open a bug on jira? Because FS behaves according to
the
design and specs :-) But not according to real world requirements...
Really, people are trying to help you and your going to be snarky in response?
On Wednesday 13 January 2010, Brian West wrote:
Can you elaborate on these "Critical" issues you seem to be having?
Why
aren't you opening a jira for them if they are that critical to your needs?
Mike
_______________________________________________ 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-user s 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
_______________________________________________ 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/ Twitter: http://twitter.com/FreeSWITCH_wire 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:+19193869900
Confirmed. r16311 has the issue resolved in both bypass_media=true/false modes. On Thursday 14 January 2010, Anthony Minessale wrote:
r16310
Thank you for the apology.
On Thu, Jan 14, 2010 at 10:41 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Anthony, I apology, I didn't expect you'll be annoyed. As for the issue, the issue is not in "proxy_media" setting, same happens when both "proxy_media" and "bypass_media" are not set. The code does explicit leg A hangup in switch_ivr_bridge.c, line 513. The condition there is "if leg A is up and leg A is not in answered state, then hangup leg A", this prevents dialplan to continue execution on early media bridge termination.
Issue when "bypass_media=true" is completely different, I'll open the issue on jira.
On Thursday 14 January 2010, Anthony Minessale wrote:
Sergey,
The bug you reference was closed because proxy_media mode by design
send's
the B leg's codec to the A LEG so if there is a failure condition there is no easy graceful way to back out and try another call. I will try to make it possible if yo post a bounty, I estimate a minimum
of
$1000USD in consulting time.
The other one I might look at once you have apologized.
I can probably add some code to make the bridge exit without terminating the A leg even when hangup_after_bridge=true in the case where the the B leg is not answered but right now I am sort of annoyed with your attitude in this thread.
On Thu, Jan 14, 2010 at 6:19 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
Case 1 (bypass_media is off) is already on jira, http://jira.freeswitch.org/browse/FSCORE-257 , I will prepare a test installation with latest trunk to reproduce case 2, when bypass_media=true and 10 seconds delay happens when 18X and then error are received on leg b.
On Wednesday 13 January 2010, Michael Jerris wrote:
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and
hangup_after_bridge
channel vars, perhaps ignore_early_media as well
- if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to
gateway
(
http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/02435
4.html ) I didn't track down yet why this happens looking at FS sources.
see response on that thread
Why I didn't open a bug on jira? Because FS behaves according to
the
design and specs :-) But not according to real world
requirements...
Really, people are trying to help you and your going to be snarky in response?
On Wednesday 13 January 2010, Brian West wrote: > Can you elaborate on these "Critical" issues you seem to be
having?
Why
> aren't you opening a jira for them if they are that critical to
your
> needs?
Mike
_______________________________________________ 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-user
_______________________________________________ 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
_______________________________________________ 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
With trunk version and bypass_media=true the behavior is different - leg a is terminated after 20 seconds of wait, dialplan can't continue. Dialplan and FS log are at http://pastebin.freeswitch.org/11794 , note timestamps of lines 378 and 379. FS is running on 192.168.1.2:5060, SIP client on 192.168.1.2:5066, 103@192.168.1.254 responds with early media and 480. Let me know if you need additional information. On Wednesday 13 January 2010, Michael Jerris wrote:
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and hangup_after_bridge channel vars, perhaps ignore_early_media as well
- if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway ( http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/02435 4.html ) I didn't track down yet why this happens looking at FS sources.
see response on that thread
Why I didn't open a bug on jira? Because FS behaves according to the design and specs :-) But not according to real world requirements...
Really, people are trying to help you and your going to be snarky in response?
On Wednesday 13 January 2010, Brian West wrote:
Can you elaborate on these "Critical" issues you seem to be having? Why aren't you opening a jira for them if they are that critical to your needs?
Mike
_______________________________________________ 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
I repeated the test without bypass_media. Leg a is terminated as soon as 480 received from leg b and dialplan doesn't continue. Let me know if you want me to post FS log to pastebin. On Thursday 14 January 2010, Sergey Okhapkin wrote:
With trunk version and bypass_media=true the behavior is different - leg a is terminated after 20 seconds of wait, dialplan can't continue. Dialplan and FS log are at http://pastebin.freeswitch.org/11794 , note timestamps of lines 378 and 379.
FS is running on 192.168.1.2:5060, SIP client on 192.168.1.2:5066, 103@192.168.1.254 responds with early media and 480.
Let me know if you need additional information.
On Wednesday 13 January 2010, Michael Jerris wrote:
On Jan 13, 2010, at 11:08 PM, Sergey Okhapkin wrote:
Critical issues are when SIP error come after 18X provisional response.
- if bypass_media is false then dialplan stops and leg a is explicitly hang up (switch_ivr_bridge.c, line 513).
behavior can be modified with continue_on_fail and hangup_after_bridge channel vars, perhaps ignore_early_media as well
- if bypass_media is true, then dialplan continue, but there is 10 seconds delay before next bridge application sends INVITE to gateway ( http://lists.freeswitch.org/pipermail/freeswitch-users/2010-January/024 35 4.html ) I didn't track down yet why this happens looking at FS sources.
see response on that thread
Why I didn't open a bug on jira? Because FS behaves according to the design and specs :-) But not according to real world requirements...
Really, people are trying to help you and your going to be snarky in response?
On Wednesday 13 January 2010, Brian West wrote:
Can you elaborate on these "Critical" issues you seem to be having? Why aren't you opening a jira for them if they are that critical to your needs?
Mike
_______________________________________________ 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
Lets move this all to jira so that we can properly track the issue. We will need full debug logs with siptrace, on current svn trunk along with dialplan and such to reproduce the issue. Mike On Jan 14, 2010, at 10:46 AM, Sergey Okhapkin wrote:
I repeated the test without bypass_media. Leg a is terminated as soon as 480 received from leg b and dialplan doesn't continue. Let me know if you want me to post FS log to pastebin.
On Thursday 14 January 2010, Sergey Okhapkin wrote:
With trunk version and bypass_media=true the behavior is different - leg a is terminated after 20 seconds of wait, dialplan can't continue. Dialplan and FS log are at http://pastebin.freeswitch.org/11794 , note timestamps of lines 378 and 379.
FS is running on 192.168.1.2:5060, SIP client on 192.168.1.2:5066, 103@192.168.1.254 responds with early media and 480.
Let me know if you need additional information.
What exactly are your problems? Is this just the "10 second" thread you posted today? Mike On Jan 13, 2010, at 10:29 PM, Sergey Okhapkin wrote:
If you wish FreeSWITCH to be well adopted by the community, then FS should follow the real world "rules" but not specs...
Don't you agree that 99% of SIP servers are set up to interconnect with "buggy" PSTN and should follow PSTN rules, but not SIP specs?
Some background - I did run asterisk for years, but switched to FS recently because of critical asterisk problems with SIP handling when asterisk is not in the media path. I spend a lot of time porting the billing system to FS. And I did it. What I got? Critical problems with FS early media handling. Hopefully I can switch back to asterisk if FS problems with early media will begin to draw customers away.
Just "10 seconds" could easily draw away customer's $$$. And seems like the process already began... :-( On Wednesday 13 January 2010, Michael Jerris wrote:
What exactly are your problems? Is this just the "10 second" thread you posted today?
Mike
On Jan 13, 2010, at 10:29 PM, Sergey Okhapkin wrote:
If you wish FreeSWITCH to be well adopted by the community, then FS should follow the real world "rules" but not specs...
Don't you agree that 99% of SIP servers are set up to interconnect with "buggy" PSTN and should follow PSTN rules, but not SIP specs?
Some background - I did run asterisk for years, but switched to FS recently because of critical asterisk problems with SIP handling when asterisk is not in the media path. I spend a lot of time porting the billing system to FS. And I did it. What I got? Critical problems with FS early media handling. Hopefully I can switch back to asterisk if FS problems with early media will begin to draw customers away.
_______________________________________________ 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
And to reiterate, you can control this to wait for first answer, at your option. These 2 modes are for totally different use cases. Mike On Jan 13, 2010, at 10:11 PM, Brian West <brian@freeswitch.org> wrote:
By all accounts its still Media and the first one to provide it in a forked dial is to be connected to the channel of the calling party even if its early... the call answer time is not started till the 200 is received.
I'm not talking about billing or answered time either.. i'm talking pure early media and how it is to be handled in FreeSWITCH.
That my friend is in the specs to behave like that.
/b
On Jan 13, 2010, at 9:05 PM, Sergey Okhapkin wrote:
Well, the question is - what is "media"? To me media is what is returned by "200 OK" response to INVITE. 18X provisional responses are NOT media, they are early media indications (well, even with RTP stream inside), which shall be sent back to the caller, but should NOT be accounted in the call processing. Early media is too early to be accounted. Only responses with SIP code 200 or more matter.
_______________________________________________ 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
How to wait for first answer and pass early media back to the caller? On Wednesday 13 January 2010, Michael Jerris wrote:
And to reiterate, you can control this to wait for first answer, at your option. These 2 modes are for totally different use cases.
Mike
On Jan 13, 2010, at 10:11 PM, Brian West <brian@freeswitch.org> wrote:
By all accounts its still Media and the first one to provide it in a forked dial is to be connected to the channel of the calling party even if its early... the call answer time is not started till the 200 is received.
I'm not talking about billing or answered time either.. i'm talking pure early media and how it is to be handled in FreeSWITCH.
That my friend is in the specs to behave like that.
/b
On Jan 13, 2010, at 9:05 PM, Sergey Okhapkin wrote:
Well, the question is - what is "media"? To me media is what is returned by "200 OK" response to INVITE. 18X provisional responses are NOT media, they are early media indications (well, even with RTP stream inside), which shall be sent back to the caller, but should NOT be accounted in the call processing. Early media is too early to be accounted. Only responses with SIP code 200 or more matter.
_______________________________________________ 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
Can you elaborate what you mean? I'm guessing you want to fork dial X calls and pass a mux version of all that early media back to the A-Leg. In which case that is 100% impossible and impractical. This scenario never happens on the PSTN. Now if you want to ignore the early media and provide your own ringback and pass media once the call is answered thats doable. http://wiki.freeswitch.org/wiki/Channel_Variables#ringback && http://wiki.freeswitch.org/wiki/Channel_Variables#ignore_early_media If this isn't the case on either one please clarify. /b On Jan 13, 2010, at 9:45 PM, Sergey Okhapkin wrote:
How to wait for first answer and pass early media back to the caller?
On Wednesday 13 January 2010, Michael Jerris wrote:
And to reiterate, you can control this to wait for first answer, at your option. These 2 modes are for totally different use cases.
Mike
What would happen if several outdials were made from a conference, rather than using a forked dial? --Dave
By all accounts its still Media and the first one to provide it in a forked dial is to be connected to the channel of the calling party even if its early... the call answer time is not started till the 200 is received.
I'm not talking about billing or answered time either.. i'm talking pure early media and how it is to be handled in FreeSWITCH.
That my friend is in the specs to behave like that.
/b
On Jan 13, 2010, at 9:05 PM, Sergey Okhapkin wrote:
Well, the question is - what is "media"? To me media is what is returned by "200 OK" response to INVITE. 18X provisional responses are NOT media, they are early media indications (well, even with RTP stream inside), which shall be sent back to the caller, but should NOT be accounted in the call processing. Early media is too early to be accounted. Only responses with SIP code 200 or more matter.
_______________________________________________ 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
Well, surely if it would work, then it's feasible and there's no reason why it shouldn't happen. Whether or not a solution will achieve the desired end result in an optimal fashion is - for most people - subordinate to getting their problem solved. Don't forget the two rules of optimisation: 1. Don't. 2. (for experts only) Don't yet. --Dave
That would work but its sub optimal. What he wants to accomplish is not do able and not going to ever happen at this rate.
/b
On Jan 13, 2010, at 9:32 PM, David Knell wrote:
What would happen if several outdials were made from a conference, rather than using a forked dial?
--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
I have never seen a carrier do this and I still doubt that it would be at all usable. What happens now is we essentially fork the dial, first with media wins. Alternatively you can wait for first answer, and provide your own ringback tones. Can you describe a bit more your use case as I just don't get it. With what you describe, I imagine a call where one leg gets a sit tone due to problem with the number and it's muxed with a ringtone of the other b leg, or ring and busy at the same time. Mike On Jan 13, 2010, at 9:10 PM, David Villasmil <david.villasmil.work@gmail.com
wrote:
MIke,
This is done on a daily basis by i.e. mobile companies, you dial a customer number and you hear some music whilst hearing the ringing at the same time.
If it can not be done by muxing both rtps, can it be done the other way, then?: (Another option is to fork the call with bridge, the bad thing is that as soon as FS receives progress/audio from 1 leg, FS discards the other one, not good for me )
Thanks
david
On Wed, Jan 13, 2010 at 9:43 PM, Michael Jerris <mike@jerris.com> wrote: Muxing 2 ringtones together would result in complete nonsense, especially in the case of custom ringback. How could this ever be usable?
Mike
On Jan 13, 2010, at 3:20 PM, David Villasmil wrote:
Thanks for answering,
Well, imagine I have a content provider which will deliver custom ringbacks via SIP INVITES, they point would be to receive A-leg then bridge to 2 B-legs and deliver both incoming rops to A-side. Another option is to fork the call with bridge, the bad thing is that as soon as FS receives progress/audio from 1 leg, FS discards the other one, not good for me :)
Thanks, and I hope you can enlighten me!
David
On Wed, Jan 13, 2010 at 6:21 PM, Michael Jerris <mike@jerris.com> wrote: Are you asking if you can mux all of the progress audio from multiple b-legs? if so, no, and why would you want to?
Mike
On Jan 13, 2010, at 6:15 AM, David Villasmil wrote:
hello
is it possible to bridge multiple b-legs and provide all audio (progress) until there is an answer on one channel?
_______________________________________________ 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
_______________________________________________ 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 (9)
-
Anthony Minessale
-
Brian West
-
Dan Lane
-
David Knell
-
David Villasmil
-
kokoska.rokoska
-
Mathieu Rene
-
Michael Jerris
-
Sergey Okhapkin