> -----Original Message----- > From: Elwell, John [mailto:[EMAIL PROTECTED] > > [JRE] That might be so, but in the Request-URI it seems to be much more > of a concern. Can anyone shed any light on what SBCs might do if a > Request URI contains both user=phone and gr=xxxx parameters? Hadriel?
That's unknowable. There are over a dozen SBC vendors, according to the analysts, possibly as many as 30 depending on your definition, though many of them are only seen in specific markets or regions. Even if you could ask all of them, they wouldn't be able to answer, because it's basically highly configurable. (and my guess is it is on other SIP devices too) I know we've had a problem with it in one case where we weren't trying to prevent it from working, but in talking with some people in IETF-Philly I'm still not sure if it was specific to our config in that case, or just a problem gruu would have even with legacy true-3261 networks in general. (my guess is it's specific to SBCs, or really any b2bua, because most b2bua's replace the Contact URI, and gruu is subsequently broken... and there are a LOT more b2bua's than just SBCs) In general though, Paul wasn't far off on the bogey-man - the whole idea of an SBC is to give total control to the owner of the SBC, imo. (I just happen to think that's ok) For example my company's SBC doesn't modify the req-uri unless it's set to, which of course most everyone does the instant they install it. In my personal opinion this type of stuff can be changed by vendors or their customers through configs, and will be if it provides value, so long as it doesn't conflict with their other goals. That's why I wrote the draft-kaplan-sip-uris-change draft. All providers want calls to work, imho. -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
