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).
for registration - even though its not a dialog - AmSipDialog is used,
and re-used, but with clearing the to-tag; e.g. for re-register or
unregister it should use same outbound proxy.
if request is resent due to authentication, it should go through same
outbound proxy.
if outbound proxy is not a record routing proxy, it should still go
through it, for subsequent requests.
I can also live with an option enforcing the outbound proxy for all
requests. Would that be OK?
yes.
if i have understood that, for the other uses, as per-dialog option
(you can have some registrations with outbound proxies, and some
without; some calls initiated from DI with outboun proxy, some
without) we can then use route.
Thanks!
Stefan
Cheers,
-Raphael.
--
Stefan Sayer
VoIP Services Consulting and Development
Warschauer Str. 24
10243 Berlin
tel:+491621366449
sip:[email protected]
email/xmpp:[email protected]
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
