Am 17.04.2011 13:54, schrieb Juha Heinanen:
Iñaki Baz Castillo writes:
Depending on our topology we can just ask for authentication for every
in-dialog request (unless it comes from a trusted node as a PSTN gw)
but without trying to check the identity of the in-dialog request
originator.
2011/4/16 Juha Heinanen j...@tutpro.com:
- Later alice sends a REFER or a re-INVITE. Note that the request
would contain From: sip:2...@domain.org (even if the AoR of alice us
sip:al...@domain.org. This is because From/To URI are usually
unchanged whithin a dialog.
inaki,
refer would
Iñaki Baz Castillo writes:
Hi Juha, Referred-By header is not part of REFER specification but an
extension (RFC 3892) and it's not mandatory:
2.1. Referrer Behavior
A UA sending a REFER request (a referrer) MAY provide a Referred-By
header field value in the request.
if refer
2011/4/17 Juha Heinanen j...@tutpro.com:
lets say that a sip ua has dialog established with pstn gw and the sip
ua sends refer to pstn gateway for the purpose of transferring the call
to another pstn destination. in that case, referred-by uri is used for
accounting of the new pstn leg.
I've
Iñaki Baz Castillo writes:
I've never seen a PSTN gw properly handling a REFER, neither I think a
PSTN gw should handle it (but a B2BUA/PBX) between the UA and the PSTN
gw(s).
i don't see any problem if gw charges the call based on referred-by that
proxy has verified. i think that even cisco
Iñaki Baz Castillo writes:
I've never seen a PSTN gw properly handling a REFER, neither I think a
PSTN gw should handle it (but a B2BUA/PBX) between the UA and the PSTN
gw(s).
inaki,
your suggestion would mean that proxy would need to route every call
between sip ua and pstn gw via a b2bua,
2011/4/11 Daniel-Constantin Mierla mico...@gmail.com:
first, skipping authentication for within dialog requests in default
configuration file comes mainly from the early years when not many sip
endpoints supported that. But can be done, of course and perhaps it should
be enabled (or at least
Iñaki Baz Castillo writes:
- Later alice sends a REFER or a re-INVITE. Note that the request
would contain From: sip:2...@domain.org (even if the AoR of alice us
sip:al...@domain.org. This is because From/To URI are usually
unchanged whithin a dialog.
inaki,
refer would contain header
Hi Eric!
Am 11.04.2011 02:09, schrieb Eric Hiller:
As I look and play with loose_route functionality it seems that by
simply placing a route: proxyip;lr header in my invite I can bypass any
and all security otherwise built into the configuration.
True!
Is this the way everyone has it?
11 apr 2011 kl. 09.25 skrev Klaus Darilion:
Hi Eric!
Am 11.04.2011 02:09, schrieb Eric Hiller:
As I look and play with loose_route functionality it seems that by
simply placing a route: proxyip;lr header in my invite I can bypass any
and all security otherwise built into the
Am 11.04.2011 10:17, schrieb Alex Balashov:
On 04/11/2011 03:25 AM, Klaus Darilion wrote:
Thus: Check for to-tag. This is how you can differ out-of-dialog
requests from in-dialog requests. Only if the to-tag is present, call
loose_route().
I suppose in principle the problem here is that
On Apr 11, 2011, at 6:23 AM, Klaus Darilion klaus.mailingli...@pernau.at
wrote:
Takeing a look at the previous problems with dialog module, and the
recent problems, I prefer to not use dialog module even in the case
someone my abuse my proxy as reflector. ;-)
Out of curiosity, to which
o Daniel-Constantin Mierla on 04/11/2011 12:53 PM:
Regarding dialog states, it is not really needed to use dialog module,
I use a lot htable for this purpose -- using call-id and the tags to
build the keys, you can track lot of attributes, as you need, e.g.,
the IP addresses, auth state, a.s.o.
On 4/11/11 1:06 PM, Stefan Sayer wrote:
o Daniel-Constantin Mierla on 04/11/2011 12:53 PM:
Regarding dialog states, it is not really needed to use dialog module,
I use a lot htable for this purpose -- using call-id and the tags to
build the keys, you can track lot of attributes, as you need,
On Monday 11 April 2011, Klaus Darilion wrote:
Am 11.04.2011 10:17, schrieb Alex Balashov:
On 04/11/2011 03:25 AM, Klaus Darilion wrote:
Thus: Check for to-tag. This is how you can differ out-of-dialog
requests from in-dialog requests. Only if the to-tag is present, call
loose_route().
On 04/11/2011 01:10 PM, Henning Westerholt wrote:
Hi Klaus,
sure, there are issues. But we're using the dialog module since now
since some time in our production setup and it works fine for this
particular feature set.
Oh, yeah. I'm a happy and extensive long-time user of the dialog
module
As I look and play with loose_route functionality it seems that by simply
placing a route: proxyip;lr header in my invite I can bypass any and all
security otherwise built into the configuration. Is this the way everyone has
it? I have been unable to find any configuration examples online that
Eric,
On 04/10/2011 08:09 PM, Eric Hiller wrote:
As I look and play with loose_route functionality it seems that by
simply placing a route: proxyip;lr header in my invite I can bypass any
and all security otherwise built into the configuration. Is this the way
everyone has it? I have been
18 matches
Mail list logo
