On 20.04.10 15:04, Stefan Sayer wrote:
Raphael Coeffic wrote:
On 20.04.10 14:20, Stefan Sayer wrote:
Hi,
Raphael Coeffic wrote:
On 20.04.10 13:56, Stefan Sayer wrote:
Hi,
but how does one set proxy for registrar client, if proxy is
different from domain?
I think that must be supported (i.e. per request, or per dialog
outbound proxy).
Also, sometimes this is used for outbound calls which are
triggered from DI.
No problem! I will add it ;-) Is that ok if the outbound proxy is
only used for the first request within a dialog?
why that limitation?
It is not a limitation, it is a feature ;-)
In section 8.1.2 of RFC 3261, it says:
"Local policy MAY specify an alternate set of destinations to attempt.
If the Request-URI contains a SIPS URI, any alternate destinations
MUST be contacted with TLS. Beyond that, there are no restrictions
on the alternate destinations if the request contains no Route header
field. This provides a simple alternative to a pre-existing route
set as a way to specify an outbound proxy. However, that approach
for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing
route set with a single URI SHOULD be used instead. If the request
contains a Route header field, the request SHOULD be sent to the
locations derived from its topmost value, but MAY be sent to any
server that the UA is certain will honor the Route and Request-URI
policies specified in this document (as opposed to those in RFC
2543). In particular, a UAC configured with an outbound proxy SHOULD
attempt to send the request to the location indicated in the first
Route header field value instead of adopting the policy of sending
all messages to the outbound proxy.
This ensures that outbound proxies that do not add Record-Route
header field values will drop out of the path of subsequent
requests. It allows endpoints that cannot resolve the first Route
URI to delegate that task to an outbound proxy.
"
This should mean for us: sending any out-of-dialog request to the
outbound proxy (this includes REGISTERs all kinds, as a registration
is not a dialog-constructing request).
a-ha. so you'd add a route made from that parameter instead? in that
case it's simple (and already there), the app could add to
AmSipDialog::route (if there were a function to access it).
That's one way of bypassing the routing logic. What the text also says
is that you should not send all the requests to some server based on
local policy, but follow the route set. By the way, the first reply
overwrites the route set based on the list of servers in the RR hf.
This means that the intended behavior is:
1. send the first request to the outbound proxy (if existing).
2. send subsequent requests using the route-set and standard behavior
(means: no outbound proxy there).
Forcing the proxy is an option, but should definitely not be the default
behavior. At least not if we claim to have some level of compliance with
standards ;-)
Cheers
Raphael.
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
