Hello,
I am trying to setup a redirecting proxy server with Ser, but I find that my GXP-2020 phone gets into an endless loop. Is this common?
The phone is configured to use my ser service which is set as a proxy. If it tries to dial things that this proxy shouldn't handle, it sends back a "305 Use Proxy" response. The phone seems to ignore the proxy and tries again.
1) Is it common for the proxy redirection not to work? I've seen it being ill-advised on iptel.org because the RFC isn't too clear how it works.
2) What would be the proper formula to get Ser to send back a proxy redirect? I may be approaching it wrongly, but I cannot find much documentation about it online.
Thanks,
Rick van Rein OpenFortress
Hi Rick,
I am trying to setup a redirecting proxy server with Ser, but I find that my GXP-2020 phone gets into an endless loop. Is this common?
The phone is configured to use my ser service which is set as a proxy. If it tries to dial things that this proxy shouldn't handle, it sends back a "305 Use Proxy" response. The phone seems to ignore the proxy and tries again.
unfortunately the usage of 305 is totally under specified. And I haven't it being used in the field ever. Anybody else maybe?
On a first look this seems to be the perfect response if you want to make the sender of a request to retry this request on a different proxy, BUT: - is a proxy on the path back allowed to consume the 305 and retry it by himself on behalf of the originator? - or is only the originator (UAC) allowed to follow the URI from the reply? - if it is only the originator: how can the originator assure that the request will traverse exactly the same path except for the last hop? Use a Route header? But when it receives the 305 response it does not know which path the original request took. - in case of the the originator trying to follow this reply: what should the UAC do in case it uses an fixed outbound proxy? Use a pre-loaded Route header with two entries? - and the biggest question: how should the URI look like which you send back in the 305 response? Just the URI of the proxy without usernames? Or should it be the complete URI which should be retried at that proxy?
Is it common for the proxy redirection not to work? I've seen it being ill-advised on iptel.org because the RFC isn't too clear how it works.
What would be the proper formula to get Ser to send back a proxy redirect? I may be approaching it wrongly, but I cannot find much documentation about it online.
I would recommend you to avoid the 305. Which also means there is nothing like a proxy redirect. You could either try to use a 301 response instead. Or you just configure the proxy to froward the request to the correct proxy instead of replying with a 305.
Best regards Nils Ohlmeier VoIP Freelancer
Hello,
(Nils: Thanks for your helpful reply.)
unfortunately the usage of 305 is totally under specified. And I haven't it being used in the field ever. Anybody else maybe?
There are good reasons for using it though. For me, these are:
1. I want to pass off any POTS calls to upstream SIP providers without having to worry about RTP proxies (setting them up, or wondering if they would be needed at all). If traffic goes through an outside-NAT proxy, the sip2pots provider would probably decide no RTP proxy is needed.
2. I want to avoid being responsible for the traffic that I pass on. This means that I can be a proxy to unregistered users, if they like. It makes it very easy for them to try out a service if they only have to set the "proxy" field in their phone.
I understand that all this reasoning won't help to improve the RFC, as this is not the task of the people on this list. I just wanted to clear up why this is useful (to me at least).
Thanks, -Rick
Hi Rick,
(Nils: Thanks for your helpful reply.)
unfortunately the usage of 305 is totally under specified. And I haven't it being used in the field ever. Anybody else maybe?
There are good reasons for using it though. For me, these are:
I want to pass off any POTS calls to upstream SIP providers without having to worry about RTP proxies (setting them up, or wondering if they would be needed at all). If traffic goes through an outside-NAT proxy, the sip2pots provider would probably decide no RTP proxy is needed.
I want to avoid being responsible for the traffic that I pass on. This means that I can be a proxy to unregistered users, if they like. It makes it very easy for them to try out a service if they only have to set the "proxy" field in their phone.
I understand that all this reasoning won't help to improve the RFC, as this is not the task of the people on this list. I just wanted to clear up why this is useful (to me at least).
sure, I totally agree that there are good use-cases for this response. But the problem seems to me that you will have to teach every SIP element in your setup how to treat this response correctly (like you expearienced already with your Grandstream phone). Good luck with that. And I would be really interested if you make progress on that front. BTW there were some discussion about this response on the IETF mailing list several years ago. But they somehow died.
Regards Nils Ohlmeier VoIP Freelancer
-
Nils Ohlmeier -
Rick van Rein