Paul Thanks so much, this confirms what I was thinking.
Yes, I was thinking of the case with ;user=phone, but I'm glad to hear that the domain is free to interpret the left hand side. Also thanks for pointing out that you also are not aware of a normative reference for that behaviour. Thanks again! On Wed, Nov 19, 2008 at 2:45 PM, Paul Kyzivat <[EMAIL PROTECTED]> wrote: > > > jorma h wrote: > >> Hi, >> >> I'd like to ask a couple of follow-on questions to this. >> >> When a proxy receives a message (e.g. INVITE) with a SIP URI containing an >> embedded tel URI, and that embedded tel URI has parameters, how is this >> handled when: >> >> >> 1. The proxy DOES NOT serve the domain in the SIP URI? >> I think the answer has to be that it simply routes on the domain, and >> completely ignores the left hand side of the URI. I.e. it does not even >> look >> at the embedded tel URI nor its parameters. >> > > yep! That would be the right thing to do. > Not everybody does it that way, but they should. > > 2. The proxy DOES serve the domain in the SIP URI? >> I'd think that in this case since it needs to process the left hand side, >> that it would take into account also the parameters of the embedded tel >> URI. >> > > When it is responsible for the domain, it is free to interpret the user > part in whatever way it thinks the domain wants it to be interpreted. > > Is this correct? >> Does anyone know of a reference for these? (I think the first case is >> clear >> in RFC 3261, not sure about the second one though.) >> > > You didn't say if the URI had user=phone or not. > > If not, then the fact that the user part happens to *look* like a tel URI > may simply be a coincidence, and has no bearing on anything. > > If it *does* have user=phone, then it should contain a > "telephone-subscriber" (syntax defined by tel uri.) But how that should be > routed is still up to the server responsible for the domain. I don't know of > anything written that normatively specifies what *must* be done in this > regard. > > Bottom line is that the domain can do as it wishes. > > Thanks, > Paul > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
