How to call multi gateways for failover with early media?
Hi, I have outbound gateways returns 403 or 503 constantly. So I tried to dial out using sofia/gateways/gw1/xxxx|sofia/gateways/gw2/xxxx|sofia/gateways/gw3... for fail over. To make it work, I need to set ignore_early_media=true. However, the caller do need to hear the early media to figure out what's going on. If I set ignore_early_media=false, only the first one tried. A little more detail: The gateway is first tier, if it cannot initiate a PSTN channel returns 403/503 immediately. If it can find a PSTN channel, but the callee fails, no answer or busy or others, it plays early media and returns 503. If I want failover, and the early media, how to do that? Thanks. regards, Seven.
dujinfang <dujinfang@gmail.com> wrote:
However, the caller do need to hear the early media to figure out what's going on. If I set ignore_early_media=false, only the first one tried.
Could you use ring_ready? that way, the calling SIP phone should generate the ringback.
First one to give media wins unless you ignore_early_media /b On Apr 3, 2009, at 6:53 PM, Jason White wrote:
Could you use ring_ready? that way, the calling SIP phone should generate the ringback.
Brian West brian@freeswitch.org -- Meet us a ClueCon! http://www.cluecon.com
On Apr 4, 2009, at 8:13 AM, Brian West wrote:
First one to give media wins unless you ignore_early_media
/b
Thanks, I tested again. That's exactly what I want except the problem sometimes the gateway gives (wrong)early_media but fails immediately, so I have no chance to hear the early media. And unfortunately the gateway is beyond my control. :( Will do more testing.
On Apr 3, 2009, at 6:53 PM, Jason White wrote:
Could you use ring_ready? that way, the calling SIP phone should generate the ringback.
Brian West brian@freeswitch.org
-- Meet us a ClueCon! http://www.cluecon.com
_______________________________________________ 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 Sat, Apr 4, 2009 at 2:41 AM, dujinfang <dujinfang@gmail.com> wrote:
On Apr 4, 2009, at 8:13 AM, Brian West wrote:
First one to give media wins unless you ignore_early_media /b
Thanks, I tested again. That's exactly what I want except the problem sometimes the gateway gives (wrong)early_media but fails immediately, so I have no chance to hear the early media. And unfortunately the gateway is beyond my control. :( Will do more testing.
I'm not really sure how else FS should handle this... As Brian said "first one with media wins". That's the problem with early media. Is it ringback that might turn into a completed call? Is it some error message played to the user? Is it someones voicemail system, trying to save some money? One way or another, is it something the user should hear? No way to know, really... 180/183 with SDP is a bit ambiguous. I always get frustrated when various people /insist/ on using 183 w/ SDP just for ringback. Have they never heard of 180 w/o SDP? Let me generate my own local ringback and/or handle the situation accordingly! -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
On Sat, 2009-04-04 at 03:32 -0400, Kristian Kielhofner wrote:
180/183 with SDP is a bit ambiguous. I always get frustrated when various people /insist/ on using 183 w/ SDP just for ringback. Have they never heard of 180 w/o SDP? Let me generate my own local ringback and/or handle the situation accordingly!
Ah, well, that's where you're trying to change the way that things have been done for some decades. Ringback has historically been generated close to the called party, which is why you hear different ringback if you call people in different countries. Furthermore, that audio path is used to convey all sorts of messages: "the number you have called has been changed", "the cellphone you have called has not responded", "calls to 1-800 numbers are not free if made from overseas.." Lastly, there's no guarantee that it'll be possible to differentiate between one of these and ringback from the signalling alone and, in many cases, there is simply no mechanism available to provide such differentiation. You're probably best advised to swim with the tide on this one..! Cheers -- Dave
Yes there was till the SIP RFC writers happen to make their ears rather sore! (RCI) 180 vs 183 should have been it... but NO they had to be ambiguous about that too... if you get a 180 without an SDP you generate... 180 or 183 with SDP (they had a sense of humor about this one I think!) Then this one tops the cake... on early media with forked dial... Say you call billy, mary and ken at the same time. Billy's address provides early media (ringing) you are to give the first one to respond with media to the caller... but if by chance Mary's phone provider is having a problem and they give congestion 20 seconds later and actually answer the call to do this cuz you know how stupid telco's are... now you are to give the caller the congestion tone... So you had prefect ringing.. then congestion... I think we have all be there, heard that! /b On Apr 5, 2009, at 10:12 PM, David Knell wrote:
signalling alone and, in many cases, there is simply no mechanism available to provide such differentiation.
Brian West wrote:
Say you call billy, mary and ken at the same time. Billy's address provides early media (ringing) you are to give the first one to respond with media to the caller... but if by chance Mary's phone provider is having a problem and they give congestion 20 seconds later and actually answer the call to do this cuz you know how stupid telco's are... now you are to give the caller the congestion tone... So you had prefect ringing.. then congestion... I think we have all be there, heard that!
Er, that's not stupidity. If the regulations allow them to answer at this point, they will. It generates revenue. Its a disaster for a lot of services which need to know if the call was answered to tell what to do next, but it ain't done through stupidity. We are the stupid suckers who pay. Steve
On Sun, Apr 5, 2009 at 11:12 PM, David Knell <dave@3c.co.uk> wrote:
Ah, well, that's where you're trying to change the way that things have been done for some decades. Ringback has historically been generated close to the called party, which is why you hear different ringback if you call people in different countries.
What's wrong with that? Isn't that what we are all doing (or trying to do), to some extent? International dialing very well may use different ringbacks but: 1) How important is this, really? 2) How much more complicated is adding at least the real potential for 180? Actually using 180 w/o SDP provides for enhanced call handing functionality while only requiring (in many cases) one additional test scenario. Consider the current example (all 180s are actually 180s w/o SDP and 183 is 183 w/ SDP): Bridging a call to multiple destinations (A, B, and C). A: 100,180 B: 100,180,200 C: 100,183 We could have implemented proper forking if it weren't for C who insisted on sending media early (for whatever reason). While I could see many scenarios where this might happen even with the configuration I suggest, consider what would happen in the ideal scenario: A: 100,180 B: 100,180,200 C: 100,180 Ah, B won because it was the first endpoint to actually /answer/ the call and begin playing media. Nice and clean. This is what happens when dialing local phones behind a PBX. All endpoint SIP phones send 180 to allow for clean parallel forking across them. This is what makes configuration for ring groups, etc, possible. I'm not suggesting that this configuration could be simply "dropped in" when dialing to the PSTN but it should at least be a a possibility. I suppose the other thing here (which is possible and has been suggested) is to configure your device to ignore early media. Too bad (due to various reasons, some of them being legacy PSTN) that in some cases the user should hear that 183. Speaking of which...
Furthermore, that audio path is used to convey all sorts of messages: "the number you have called has been changed", "the cellphone you have called has not responded", "calls to 1-800 numbers are not free if made from overseas.." Lastly, there's no guarantee that it'll be possible to differentiate between one of these and ringback from the signalling alone and, in many cases, there is simply no mechanism available to provide such differentiation.
People poke at SIP all the time for this one but this is where the PSTN even seems a bit ambiguous. We have ISDN cause codes AND inband audio messages? I'm reminded of a situation the other day with a provider's SIP architecture. If you send a call to a completely bogus destination number (1, in this case) they reply with an inband audio error message. Why not send a 404 or something that is easily parsed and understood by my platform (FreeSWITCH)? In this case I needed to do some further action in the event of a "call failure" and as far as bridge/mod_sofia is concerned this was a "successful" call. I know this specific instance could be avoided but I can't wait to see what else they play inband audio messages for. Of course I can't really configure my end to ignore early media because I could miss out on some legit inband audio messaging that is actually useful.
You're probably best advised to swim with the tide on this one..!
If I "swam with the tide" I'd probably be out getting my CCIE and installing Call Manager systems or something ;). Maybe that's not the best or the most "fair" analogy but hopefully you can see my point. I think there's a little rebel in all of us here on freeswitch-users! -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
Kristian Kielhofner wrote:
On Sun, Apr 5, 2009 at 11:12 PM, David Knell <dave@3c.co.uk> wrote:
Ah, well, that's where you're trying to change the way that things have been done for some decades. Ringback has historically been generated close to the called party, which is why you hear different ringback if you call people in different countries.
What's wrong with that? Isn't that what we are all doing (or trying to do), to some extent?
International dialing very well may use different ringbacks but:
1) How important is this, really? 2) How much more complicated is adding at least the real potential for 180?
The actual ringback tone may not be important, but many other supervisory indications may occur at that point, either as tones or as voice announcements. E.g. call a cellphone that has problems - out of range, out of service, etc - and you will probably get a voice announcement telling you want's up. Steve
On Mon, 2009-04-06 at 00:08 -0400, Kristian Kielhofner wrote:
Actually using 180 w/o SDP provides for enhanced call handing functionality while only requiring (in many cases) one additional test scenario. Consider the current example (all 180s are actually 180s w/o SDP and 183 is 183 w/ SDP):
Bridging a call to multiple destinations (A, B, and C).
A: 100,180 B: 100,180,200 C: 100,183
We could have implemented proper forking if it weren't for C who insisted on sending media early (for whatever reason). While I could see many scenarios where this might happen even with the configuration I suggest, consider what would happen in the ideal scenario:
A: 100,180 B: 100,180,200 C: 100,180
Ah, B won because it was the first endpoint to actually /answer/ the call and begin playing media. Nice and clean.
Hang on - if you want to bridge the call on *answer*, then bridge it on answer, not when one leg starts sending you early media. I've no idea if FS supports this behaviour for its forked dialling, but it's easy to do with a bunch of originates, and uuid_bridge the inbound leg to the first one which answers.
People poke at SIP all the time for this one but this is where the PSTN even seems a bit ambiguous. We have ISDN cause codes AND inband audio messages?
Yes. A clearing code is used when the call's cleared; inband audio can be used to give the caller more information than a simple clearing code might allow - for example, "The number you are calling has been changed. Please redial on whatever the new number might be." It makes eminent sense - simple, common causes (e.g. user busy) get dealt with as part of the call clearing and it's the responsibility of the originating switch to tell the user; more (indeed arbitrarily) complex ones are dealt with by the far end. --Dave
The default in originate is to return as soon as there is media. So if you bridge an inbound call, FS core will use originate to establish the outbound leg, as soon as it gets media (18X + sdp) it will return and enter the bridge in early media, this allows you to hear the early media while you are waiting for answer. If you want to wait for answer you add {ignore_early_media=true} to the dial string which tells originate to wait for answer or hangup before returning. if you are doing a forked dial and you don't just want the first one that has media to send a 183, you need to also enable {ignore_early_media=true} for that call. On Mon, Apr 6, 2009 at 8:47 AM, David Knell <dave@3c.co.uk> wrote:
On Mon, 2009-04-06 at 00:08 -0400, Kristian Kielhofner wrote:
Actually using 180 w/o SDP provides for enhanced call handing functionality while only requiring (in many cases) one additional test scenario. Consider the current example (all 180s are actually 180s w/o SDP and 183 is 183 w/ SDP):
Bridging a call to multiple destinations (A, B, and C).
A: 100,180 B: 100,180,200 C: 100,183
We could have implemented proper forking if it weren't for C who insisted on sending media early (for whatever reason). While I could see many scenarios where this might happen even with the configuration I suggest, consider what would happen in the ideal scenario:
A: 100,180 B: 100,180,200 C: 100,180
Ah, B won because it was the first endpoint to actually /answer/ the call and begin playing media. Nice and clean.
Hang on - if you want to bridge the call on *answer*, then bridge it on answer, not when one leg starts sending you early media. I've no idea if FS supports this behaviour for its forked dialling, but it's easy to do with a bunch of originates, and uuid_bridge the inbound leg to the first one which answers.
People poke at SIP all the time for this one but this is where the PSTN even seems a bit ambiguous. We have ISDN cause codes AND inband audio messages?
Yes. A clearing code is used when the call's cleared; inband audio can be used to give the caller more information than a simple clearing code might allow - for example, "The number you are calling has been changed. Please redial on whatever the new number might be." It makes eminent sense - simple, common causes (e.g. user busy) get dealt with as part of the call clearing and it's the responsibility of the originating switch to tell the user; more (indeed arbitrarily) complex ones are dealt with by the far end.
--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
On Apr 4, 2009, at 7:53 AM, Jason White wrote:
dujinfang <dujinfang@gmail.com> wrote:
However, the caller do need to hear the early media to figure out what's going on. If I set ignore_early_media=false, only the first one tried.
Could you use ring_ready? that way, the calling SIP phone should generate the ringback.
ring_ready would be replaced by remote party early media. It does not harm though, I still need to listen early media. Thanks.
_______________________________________________ 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
-
Brian West
-
David Knell
-
dujinfang
-
Jason White
-
Kristian Kielhofner
-
Steve Underwood