> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > > My personal opinion is that the kind of checking you are talking about > is just "meddling" in the affairs of the UAs, and should not be done. > But I suppose one might desire a policy that enforces standards in this > way. But if so, as a UA I don't want my agents enforcing policies that > prevent valid usages by my UA. > > Perhaps Hadriel would like to comment on this. His company makes SBCs > that I think are in the business of sticking their nose into other > people's sip usage and policing it.
Cute. I believe Christer's makes them too, as does yours, and a dozen others on this list. We don't "stick our nose into other people's usage". They sent SIP to us. We can't force a UA not to send something to us. But it doesn't mean we have to accept it. No one forces you to send your SIP requests to us or any SBC, AFAIK. > Do they do this kind of enforcement? Of course we could do that kind of enforcement, depending on configuration, as I assume you guys do. My guess is even "Proxies" do it, based on config. (and there are plenty of record-routing proxies) The RFCs say to forward SIP requests, just as they expect routers to forward packets, but that doesn't stop routers from having ACLs, policing, shaping, filtering routes, etc. Email servers block emails based on usage too. Regardless, I'm with you that we can't consider local device policies as a roadblock to all new things. (Although pragmatism has its place) It's just that it is an advantage for a mechanism if we know it works in more cases due to empirical evidence. I think there is also some evidence that a Notify in an Invite dialog works, because there is at least one vendor out there that uses Notify in an Invite for DTMF. But many more do Info, I believe, so I assume its chance of success is greater. -hadriel _______________________________________________ Sip mailing list https://www1.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
