19 Oct
2012
19 Oct
'12
4:58 p.m.
Hi,
MSRP AUTH requests must be authenticated using HTTP Digest
authentication. Part of the concatenated data when doing this
authentication is the method name. Because of the way MSRP requests are
formatted, the part of the request-line that would contain the method
name in HTTP or SIP requests is always MSRP. The MSRP method name (AUTH
in this case) is at the end of the request-line. When Kamailio converts
an MSRP request to SIP it has a method name of MSRP.
This means that when Kamailio authenticates an MSRP request it uses
"MSRP" as the method name, not the actual MSRP method name (AUTH).
Is this correct?
Should MSRP requests be authenticated with a method name of
"MSRP" (which kind-of makes sense as this is the string at the start of
the MSRP request line - which is where the method names are in HTTP and
SIP) or should the MSRP method name of "AUTH" be used?
If it is the later, does anyone know of an easy way to add this to
Kamailio?
Regards,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
25 Oct
25 Oct
2:16 p.m.
Hello,
just remembered about this one ...
hmm, I would say now that the right method would be AUTH, not MSRP, but
as you pointed, in SIP and HTTP the method is the first token in
request. I guess you had no chance to test with some client or look at
specs to see if they clarify somehow.
In both cases, the method seems to be static anyhow, either AUTH or MSRP
(iirc, the authentication is done only for AUTH). Both have the same
length, so a quick hack would be to replace internally MSRP with AUTH
for this case. But probably the safest is to extend the auth api with a
function that takes the method as parameter, which is eventually used
from inside msrp module.
Probably before the next release I will put some efforts in this module,
as the interest on it seems to increase, one of the goals being to add
an internal hash table to track the connections - it should bring some
performance improvement versus using htable in config...
Cheers,
Daniel
On 10/19/12 3:58 PM, Peter Dunkley wrote:
Hi,
MSRP AUTH requests must be authenticated using HTTP Digest
authentication. Part of the concatenated data when doing this
authentication is the method name. Because of the way MSRP requests
are formatted, the part of the request-line that would contain the
method name in HTTP or SIP requests is always MSRP. The MSRP method
name (AUTH in this case) is at the end of the request-line. When
Kamailio converts an MSRP request to SIP it has a method name of MSRP.
This means that when Kamailio authenticates an MSRP request it uses
"MSRP" as the method name, not the actual MSRP method name (AUTH).
Is this correct?
Should MSRP requests be authenticated with a method name of "MSRP"
(which kind-of makes sense as this is the string at the start of the
MSRP request line - which is where the method names are in HTTP and
SIP) or should the MSRP method name of "AUTH" be used?
If it is the later, does anyone know of an easy way to add this to
Kamailio?
Regards,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
2:40 p.m.
Hi,
I am doing some work on this module right now myself.
I did think of putting a bit of code into the auth module that, where
the method is selected, checks to see if the request is an MSRP one and,
if it is, selects the method using the same mechanism as for
$msrp(method).
I am also looking at the handling of the To-Path: header as I am not
sure that is correct. If I have two MSRP clients connected to the same
relay my To-Path: header in a SEND will be:
To-Path: msrps://relay_address:relay_port/foo \ <-- From the Use-Path: in response
to _MY_ AUTH
msrps://relay_address:relay_port/bar \ <-- From the Use-Path: in response to peers
AUTH
msrps://client_address:client_port/wibble <-- Peer
This is based on RFC 4967 section 5.1 paragraph three:
... To form the To-Path header for outgoing
requests, the client takes the list of URIs in the Use-Path header
after the outermost authentication and appends the list of URIs
provided in the path attribute in the peer's session description. ...
The example event_route[] in the MSRP README contains the following
logic for SEND handling:
if($msrp(nexthops)>1)
{
msrp_reply("200", "Received");
msrp_relay();
exit;
}
$var(sessid) = $msrp(sessid);
if($sht(msrp=>$var(sessid)::srcaddr) == $null)
{
# one more hop, but we don't have address in htable
msrp_reply("481", "No Such Session");
exit;
}
msrp_relay_flags("1");
msrp_set_dst("$sht(msrp=>$var(sessid)::srcaddr)",
"$sht(msrp=>$var(sessid)::srcsock)");
msrp_relay();
exit;
}
But I seem to have problems with this as the msrp_relay() when
$msrp(nexthops) > 1 fails (this could be related to my changes for WS
support as it is a problem finding/creating a TCP connection to the next
relay). However, ideally the MSRP relay should spot that the first two
URIs on the To-Path: are itself and eat them both - setting $msrp(...)
appropriately - rather than looping MSRP requests back to itself.
Also, I think the same handling should be performed for routing REPORT
requests too - so the overall logic of the MSRP event_route[] should be:
if (msrp_is_reply())
msrp_relay();
else if ($msrp(method) == "AUTH") {
...
} else if ($msrp(method) == "SEND" || $msrp(method) ==
"REPORT") {
...
} else
msrp_reply("501", "Request-method-not-understood");
Regards,
Peter
On Thu, 2012-10-25 at 13:16 +0200, Daniel-Constantin Mierla wrote:
Hello,
just remembered about this one ...
hmm, I would say now that the right method would be AUTH, not MSRP,
but as you pointed, in SIP and HTTP the method is the first token in
request. I guess you had no chance to test with some client or look at
specs to see if they clarify somehow.
In both cases, the method seems to be static anyhow, either AUTH or
MSRP (iirc, the authentication is done only for AUTH). Both have the
same length, so a quick hack would be to replace internally MSRP with
AUTH for this case. But probably the safest is to extend the auth api
with a function that takes the method as parameter, which is
eventually used from inside msrp module.
Probably before the next release I will put some efforts in this
module, as the interest on it seems to increase, one of the goals
being to add an internal hash table to track the connections - it
should bring some performance improvement versus using htable in
config...
Cheers,
Daniel
On 10/19/12 3:58 PM, Peter Dunkley wrote:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
Hi,
MSRP AUTH requests must be authenticated using HTTP Digest
authentication. Part of the concatenated data when doing this
authentication is the method name. Because of the way MSRP requests
are formatted, the part of the request-line that would contain the
method name in HTTP or SIP requests is always MSRP. The MSRP method
name (AUTH in this case) is at the end of the request-line. When
Kamailio converts an MSRP request to SIP it has a method name of
MSRP.
This means that when Kamailio authenticates an MSRP request it uses
"MSRP" as the method name, not the actual MSRP method name (AUTH).
Is this correct?
Should MSRP requests be authenticated with a method name of
"MSRP" (which kind-of makes sense as this is the string at the start
of the MSRP request line - which is where the method names are in
HTTP and SIP) or should the MSRP method name of "AUTH" be used?
If it is the later, does anyone know of an easy way to add this to
Kamailio?
Regards,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
5:08 p.m.
Hello,
On 10/25/12 1:40 PM, Peter Dunkley wrote:
Hi,
I am doing some work on this module right now myself.
I did think of putting a bit of code into the auth module that, where
the method is selected, checks to see if the request is an MSRP one
and, if it is, selects the method using the same mechanism as for
$msrp(method).
I would avoid to put lot of dependent code in auth -- maybe in the
future we need to refactor how msrp packets are presented or to auth
some other protocol. It should be easier to maintain just to pass the
relevant tokens from outside.
I am also looking at the handling of the To-Path: header as I am not
sure that is correct. If I have two MSRP clients connected to the
same relay my To-Path: header in a SEND will be:
To-Path: msrps://relay_address:relay_port/foo \ <-- From the Use-Path: in response
to _MY_ AUTH
msrps://relay_address:relay_port/bar \ <-- From the Use-Path: in response to peers
AUTH
msrps://client_address:client_port/wibble <-- Peer
This is based on RFC 4967 section 5.1 paragraph three:
... To form the To-Path header for outgoing
requests, the client takes the list of URIs in the Use-Path header
after the outermost authentication and appends the list of URIs
provided in the path attribute in the peer's session description. ...
The example event_route[] in the MSRP README contains the following
logic for SEND handling:
if($msrp(nexthops)>1)
{
msrp_reply("200", "Received");
msrp_relay();
exit;
}
$var(sessid) = $msrp(sessid);
if($sht(msrp=>$var(sessid)::srcaddr) == $null)
{
# one more hop, but we don't have address in htable
msrp_reply("481", "No Such Session");
exit;
}
msrp_relay_flags("1");
msrp_set_dst("$sht(msrp=>$var(sessid)::srcaddr)",
"$sht(msrp=>$var(sessid)::srcsock)");
msrp_relay();
exit;
}
But I seem to have problems with this as the msrp_relay() when
$msrp(nexthops) > 1 fails (this could be related to my changes for WS
support as it is a problem finding/creating a TCP connection to the
next relay). However, ideally the MSRP relay should spot that the
first two URIs on the To-Path: are itself and eat them both - setting
$msrp(...) appropriately - rather than looping MSRP requests back to
itself.
Indeed, it would be good to skip all local paths, but even not, opening
connection to itself should work. If you have troubles, then maybe
something else got broken.
Also, I think the same handling should be performed for routing REPORT
requests too - so the overall logic of the MSRP event_route[] should be:
if (msrp_is_reply())
msrp_relay();
else if ($msrp(method) == "AUTH") {
...
} else if ($msrp(method) == "SEND" || $msrp(method) == "REPORT")
{
...
} else
msrp_reply("501", "Request-method-not-understood");
Is REPORT end to end?
Cheers,
Daniel
Regards,
Peter
On Thu, 2012-10-25 at 13:16 +0200, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
Hello,
just remembered about this one ...
hmm, I would say now that the right method would be AUTH, not MSRP,
but as you pointed, in SIP and HTTP the method is the first token in
request. I guess you had no chance to test with some client or look
at specs to see if they clarify somehow.
In both cases, the method seems to be static anyhow, either AUTH or
MSRP (iirc, the authentication is done only for AUTH). Both have the
same length, so a quick hack would be to replace internally MSRP with
AUTH for this case. But probably the safest is to extend the auth api
with a function that takes the method as parameter, which is
eventually used from inside msrp module.
Probably before the next release I will put some efforts in this
module, as the interest on it seems to increase, one of the goals
being to add an internal hash table to track the connections - it
should bring some performance improvement versus using htable in
config...
Cheers,
Daniel
On 10/19/12 3:58 PM, Peter Dunkley wrote:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
Hi,
MSRP AUTH requests must be authenticated using HTTP Digest
authentication. Part of the concatenated data when doing this
authentication is the method name. Because of the way MSRP requests
are formatted, the part of the request-line that would contain the
method name in HTTP or SIP requests is always MSRP. The MSRP method
name (AUTH in this case) is at the end of the request-line. When
Kamailio converts an MSRP request to SIP it has a method name of MSRP.
This means that when Kamailio authenticates an MSRP request it uses
"MSRP" as the method name, not the actual MSRP method name (AUTH).
Is this correct?
Should MSRP requests be authenticated with a method name of "MSRP"
(which kind-of makes sense as this is the string at the start of the
MSRP request line - which is where the method names are in HTTP and
SIP) or should the MSRP method name of "AUTH" be used?
If it is the later, does anyone know of an easy way to add this to
Kamailio?
Regards,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda>
-http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 -http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -http://asipto.com/u/katu
11:38 p.m.
On Thu, 2012-10-25 at 16:08 +0200, Daniel-Constantin Mierla wrote:
I would avoid to put lot of dependent code in auth --
maybe in the
future we need to refactor how msrp packets are presented or to auth
some other protocol. It should be easier to maintain just to pass the
relevant tokens from outside.
I have done this now.
Indeed, it would be good to skip all local paths, but
even not,
opening connection to itself should work. If you have troubles, then
maybe something else got broken.
Something else was broken by me. Should be fixed now.
Is REPORT end to end?
I have updated the example in the README to do the right thing (I think)
with reports and to use the new authentication functions.
Regards,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
4411
days inactive
4417
days old
4 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Peter Dunkley