Inaki, Actually, I think this the essence of SIP proxy, have you ever imagined why mid-dialog req get passed through proxy? IMO, after proxy populates the target(s) (usually, proxy would not responsible for the uri,since it's remote peer's contact uri, the target is just the same as req-uri), so proxy would just forward the req based on top route if any, or req-uri. The forwarding-on-top-route policy ensure the routeset get traversed one-by-one.
Most of proxies would have no idea of dialog, it just follow the steps to handle mid-dialog/out-of-dialog requests. And normally, there would no route header left when out-of-dialog arrives at proxy, the preloaded routeset is just a recommended way of RFC3261 to specify outbound proxy. FYI -Rockson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz Castillo Sent: Monday, September 08, 2008 4:29 PM Cc: [email protected] Subject: Re: [Sip-implementors] Question on proxy routing 2008/9/8, Rockson Li (zhengyli) <[EMAIL PROTECTED]>: > Franz, > > IMO, the proxy need first replace the req-uri with target, and > forward the request to next hop based top route. > > The reason is as per RFC3261 > > 1)Proxy first Determining Request Targets based on req-uri 2)then > forward the req > 2.1) update the req-uri with target(16.6 Request Forwarding item 2) > 2.2) forward the req based on top route or req-uri (16.6 Request > Forwarding item 7) Well, I couldn't believe this but after re-read that section it seems to be the expected behaviour (behaviour expected just for people writting RFC's in other planets, not for any common user/implementor in this real world). IMHO it makes no sense at all that the UAC decides how the proxy responsible for the AoR must forward the request to the destination contact. It's supposed that the proxy knows that info better than any other element since the proxy can ask the location service. Maybe there is a hyper-exotic case in which this behaviour makes sense (defined probably in a not implemented draft), but IMHO this is a security risk. Imagine the following case: - User A (a bad user) sends an INVITE to proxy P: INVITE sip:[EMAIL PROTECTED] SIP/2.0 Route: <sip:[EMAIL PROTECTED];user=phone> - The INVITE arrives to proxy P who is responsible for that domain so asks the location service and finds the target "sip:[EMAIL PROTECTED]". - But there is a Route header, and note that is a STRICT ROUTER since there is no "lr" parameter. - Then the proxy must send the request to gateway_pstn in strict route mode so it generates the following request and sends it to gateway_pstn: INVITE sip:[EMAIL PROTECTED];user=phone SIP/2.0 Route: <sip:[EMAIL PROTECTED]> - The INVITE arrives to gateway_pstn who is simpler (it will not perform those strage and exotic operations) and probably will ignore the "Route" header. - So we have a call to the PSTN, probably not properly accounted by the proxy P since it thought it was a call to a local SIP user. Well, this is the reason that requests with RURI domain matching proxy domains and a Route header should be forbidden in the proxy. But it's RFC3261 who permits so dangerous issues like this. -- Iñaki Baz Castillo <[EMAIL PROTECTED]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
