Hi!
catalina oancea schrieb:
No, actually the value in the received parameter is not equal to the IP in the Via. I looked in the code and this seems to be the intended behavior. It would be nice to be able to disable it, but I don't think there is one.
Then it is standard conform. If the request is received from a different address then advertised, this parameter must be added.
This is because SIP requires to send the response to the IP address from which the request was received.
regards klaus
Thanks anyway Catalina
2009/7/16 Klaus Darilion klaus.mailinglists@pernau.at:
catalina oancea wrote:
Form what I found in http://lists.kamailio.org/pipermail/devel/2008-August/015080.html, it seems to me that it's a bug that kamailio adds received=IP parameter although force_rport was not called.
The bug was something else.
Does anybody know how to disable the received=IP Via parameter that is added by default from kamailio? For the case I want to disable it in, I have no NAT handling. Also, I have: dns=no rev_dns=no
In this case "received" will only be added if the advertised IP is different than the IP from which the request was received. (according to RFC).
So, you do not use rport but kamailio adds the received parameter and the value in the received parameter is identical to the IP in the Via?
regards klaus
Catalina,
Klaus is right. See RFC 3261 18.2.1 ("Receiving Requests"):
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.
-- Alex
Hi!
catalina oancea schrieb:
No, actually the value in the received parameter is not equal to the IP in the Via. I looked in the code and this seems to be the intended behavior. It would be nice to be able to disable it, but I don't think there is one.
Then it is standard conform. If the request is received from a different address then advertised, this parameter must be added.
This is because SIP requires to send the response to the IP address from which the request was received.
regards klaus
Thanks anyway Catalina
2009/7/16 Klaus Darilion klaus.mailinglists@pernau.at:
catalina oancea wrote:
Form what I found in http://lists.kamailio.org/pipermail/devel/2008-August/015080.html, it seems to me that it's a bug that kamailio adds received=IP parameter although force_rport was not called.
The bug was something else.
Does anybody know how to disable the received=IP Via parameter that is added by default from kamailio? For the case I want to disable it in, I have no NAT handling. Also, I have: dns=no rev_dns=no
In this case "received" will only be added if the advertised IP is different than the IP from which the request was received. (according to RFC).
So, you do not use rport but kamailio adds the received parameter and the value in the received parameter is identical to the IP in the Via?
regards klaus
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Ok if it's according to the rfc I guess I must accept it.
Thanks Catalina
2009/7/17 Alex Balashov abalashov@evaristesys.com:
Catalina,
Klaus is right. See RFC 3261 18.2.1 ("Receiving Requests"):
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.
-- Alex
Hi!
catalina oancea schrieb:
No, actually the value in the received parameter is not equal to the IP in the Via. I looked in the code and this seems to be the intended behavior. It would be nice to be able to disable it, but I don't think there is one.
Then it is standard conform. If the request is received from a different address then advertised, this parameter must be added.
This is because SIP requires to send the response to the IP address from which the request was received.
regards klaus
Thanks anyway Catalina
2009/7/16 Klaus Darilion klaus.mailinglists@pernau.at:
catalina oancea wrote:
Form what I found in http://lists.kamailio.org/pipermail/devel/2008-August/015080.html, it seems to me that it's a bug that kamailio adds received=IP parameter although force_rport was not called.
The bug was something else.
Does anybody know how to disable the received=IP Via parameter that is added by default from kamailio? For the case I want to disable it in, I have no NAT handling. Also, I have: dns=no rev_dns=no
In this case "received" will only be added if the advertised IP is different than the IP from which the request was received. (according to RFC).
So, you do not use rport but kamailio adds the received parameter and the value in the received parameter is identical to the IP in the Via?
regards klaus
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775
catalina oancea schrieb:
Ok if it's according to the rfc I guess I must accept it.
of course you could hack the source code - should be rather easy to not add the parameter. Nevertheless I never heard of any issues due to this parameter.
regards klaus
On 17.07.2009 16:19 Uhr, Klaus Darilion wrote:
catalina oancea schrieb:
Ok if it's according to the rfc I guess I must accept it.
of course you could hack the source code - should be rather easy to not add the parameter. Nevertheless I never heard of any issues due to this parameter.
just in case this "personalization" is really needed for someone, the place to look at is msg_translator.c in core, function received_test().
Cheers, Daniel
-
Alex Balashov -
catalina oancea -
Daniel-Constantin Mierla -
Klaus Darilion