<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
<div class="moz-cite-prefix">On 10/25/12 1:40 PM, Peter Dunkley
wrote:<br>
</div>
<blockquote cite="mid:1351165234.1932.52.camel@pd-notebook-linux"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="GENERATOR" content="GtkHTML/4.4.4">
Hi,<br>
<br>
I am doing some work on this module right now myself.<br>
<br>
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).<br>
</blockquote>
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.<br>
<br>
<blockquote cite="mid:1351165234.1932.52.camel@pd-notebook-linux"
type="cite">
<br>
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:
<pre> 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
</pre>
<br>
This is based on RFC 4967 section 5.1 paragraph three:
<pre> ... 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. ...
</pre>
<br>
The example event_route[] in the MSRP README contains the
following logic for SEND handling:
<pre> 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;
}
</pre>
<br>
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.<br>
</blockquote>
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.<br>
<br>
<blockquote cite="mid:1351165234.1932.52.camel@pd-notebook-linux"
type="cite">
<br>
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:<br>
<br>
<blockquote>
<pre>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");</pre>
</blockquote>
</blockquote>
Is REPORT end to end?<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<blockquote cite="mid:1351165234.1932.52.camel@pd-notebook-linux"
type="cite">
<blockquote>
<pre>
</pre>
</blockquote>
<br>
Regards,<br>
<br>
Peter<br>
<br>
<br>
On Thu, 2012-10-25 at 13:16 +0200, Daniel-Constantin Mierla wrote:<br>
<blockquote type="CITE"> Hello,<br>
<br>
just remembered about this one ...<br>
<br>
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.<br>
<br>
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.<br>
<br>
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...<br>
<br>
Cheers,<br>
Daniel<br>
<br>
</blockquote>
<blockquote type="CITE"> On 10/19/12 3:58 PM, Peter Dunkley wrote:<br>
<br>
</blockquote>
<blockquote type="CITE">
<blockquote type="CITE"> Hi,<br>
<br>
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.<br>
<br>
This means that when Kamailio authenticates an MSRP request it
uses "MSRP" as the method name, not the actual MSRP method
name (AUTH).<br>
<br>
Is this correct?<br>
<br>
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?<br>
<br>
If it is the later, does anyone know of an easy way to add
this to Kamailio?<br>
<br>
Regards,<br>
<br>
Peter<br>
<br>
<table cellpadding="0" cellspacing="0" width="100%">
<tbody>
<tr>
<td>
<pre>--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</pre>
</td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>_______________________________________________
sr-dev mailing list
<a moz-do-not-send="true" href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a>
<a moz-do-not-send="true" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a>
</pre>
</blockquote>
<br>
<pre>--
Daniel-Constantin Mierla - <a moz-do-not-send="true" href="http://www.asipto.com">http://www.asipto.com</a>
<a moz-do-not-send="true" href="http://twitter.com/#%21/miconda">http://twitter.com/#!/miconda</a> - <a moz-do-not-send="true" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - <a moz-do-not-send="true" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a>
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - <a moz-do-not-send="true" href="http://asipto.com/u/katu">http://asipto.com/u/katu</a>
</pre>
</blockquote>
<br>
<table cellpadding="0" cellspacing="0" width="100%">
<tbody>
<tr>
<td>
<pre>--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</pre>
</td>
</tr>
</tbody>
</table>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - <a class="moz-txt-link-freetext" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a>
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - <a class="moz-txt-link-freetext" href="http://asipto.com/u/katu">http://asipto.com/u/katu</a></pre>
</body>
</html>