On Sun, Apr 5, 2009 at 11:12 PM, David Knell <[email protected]> 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 _______________________________________________ Freeswitch-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
