<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
opening this for discussion to get more eyes on the IETF specs to be
sure I haven't missed any requirements.<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<p>We are no adding received parameter to Via header as required by
RFC 3261:</p>
<p> 18.2.1 Receiving Requests</p>
<p>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</p>
<pre> When the server transport receives a request over any transport, it
MUST examine the value of the "sent-by" parameter in the top Via
header field value. If the host portion of the "sent-by" parameter
contains a domain name, or if it contains an IP address that differs
from the packet source address, the server MUST add a "received"
parameter to that Via header field value. This parameter MUST
contain the source address from which the packet was received. This
is to assist the server transport layer in sending the response,
since it must be sent to the source IP address from which the request
came.</pre>
<br>
But then RFC3581 says:<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<pre>4. Server Behavior
The server behavior specified here affects the transport processing
defined in Section 18.2 of SIP [1].
When a server compliant to this specification (which can be a proxy
or UAS) receives a request, it examines the topmost Via header field
value. If this Via header field value contains an "rport" parameter
with no value, it MUST set the value of the parameter to the source
port of the request. This is analogous to the way in which a server
will insert the "received" parameter into the topmost Via header
field value. In fact, the server MUST insert a "received" parameter
containing the source IP address that the request came from, even if
it is identical to the value of the "sent-by" component. Note that
this processing takes place independent of the transport protocol.
</pre>
I understand that if rport parameter is present in incoming Via,
received has to be added always, even when matching the IP address
in via. RFC3261 required to be added only when it source IP was
different than the address in Via.<br>
<br>
On the other hand, the RFC3261 says received is needed for helping
the server to route back the reply, so received shouldn't make much
sense for upstream. However, apparently, some clients use it (or at
least check it and don't work properly if not present after a rport
-- one specific example is that some phone is not making calls after
sending REGISTER with rport and not receiving received).<br>
<br>
RFC3581 says that server behavior affect what was specified in 3261,
so my plan is to send received always if rport is present, but I
wanted to see if anyone sees issues with that or there is another
more recent rfc amending further the behaviour related to rport.<br>
<br>
Cheers,<br>
Daniel<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<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>
Next Kamailio Advanced Trainings 2014 - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
Sep 22-25, Berlin, Germany</pre>
</body>
</html>