> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > > In this case what I had in mind (by referring to a "call back") was that > I gave it to you in a From-URI.
Ah, ok. The only issue then is that when a UAC generates a request, it's not really clear how it should know when it wants things back *only* via SIP, or when it doesn't care. For example, if you make a phone call, why would your UAC use a From-URI of TEL? It would (typically) be your registered AoR, and sip:[EMAIL PROTECTED] And yet I doubt very much that most phones, or their users, really care whether people calling them *back* go through the PSTN or not to reach their SIP phone. I bet most of them have no idea they're even *using* a SIP phone. > >> If you want some server on the originating end to do something for the > >> outbound call, then you should put a Route header in the request > >> identifying the server. > > > > And I wish that would work, but in many cases it won't. > > AFAIK we are in the business of determining the valid ways of doing > things. If implementations choose to do otherwise all we can do is keep > encouraging. Absolutely. But pragmatism has its place too. (I'm not saying this is one of those times though) > The problem with trying to make up for the inadequacies of the neighbors > is - how do you know which ones do it right and which do it wrong? With some things it's part of the peering agreement (e.g., a "profile"), with some things it's based on device-specific config or vendor-profiles. But for some things it's a lowest-common-denominator: change it to what works with every device. > I guess you SBC guys can keep getting the business to try to solve that > problem. But it really means a bunch of configuration about the > idiosyncrasies of all the peers. That only works when there are a > limited number of them. Yup, and why I'm trying to get things to stop needing to be "fixed". It's not core to an SBC's value prop, and not a good long-term strategy for such. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
