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