On Apr 15, 2012, at 12:39 PM, Olle E. Johansson wrote: > > 15 apr 2012 kl. 19:31 skrev Kevin P. Fleming: > >> On 04/15/2012 12:23 PM, Vineet Menon wrote: >> >>> Ya I agree that initiating a new transaction just for convey non-auth. >>> seems messy..... >> >> i think you've missed the important point here: if you send a SIP >> request to a UAS, you are implicitly authorizing them to respond to that >> request. It doesn't seem like there would be any value in requiring a >> UAS to be required to authenticate itself in order to respond to a request. >> > Do remember that a SIP request can fork, so the CALLER might not > have a relation to the UA or identity that answers. > > There are calls where you want bidirectional assured identity.
We used to call this the "forking unanticipated respondent problem". It's part of why I'm no longer allowed to suggest deprecating forking. It's actually so common that it's a large part of why RFC 4474 didn't really catch on. Calls are often going to somebody that the caller really isn't prepared to accept an answer from, and without Identity, it usually just works. Oddly enough, I noticed the same thing happening in university when people drank too much at the bar. They sometimes ended up in sessions with people they didn't really know, having been "proxied" off" by others. Hence we might term a calling party that doesn't police identities on respondents "promiscuous". Most SIP UAs these days really are indiscriminately promiscuous. Not only will they take an "OK" response from UAs with which they have no pre-existing relationship, they'll accept media from anybody who streams it to the right IP address and port. I believe that when I was attending university, we mostly attributed this sort of behavior to the students of our rival school ... -- Dean _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
