On Wednesday 05 February 2014 12:04:02 Andrew Pogrebennyk wrote:
On 02/05/2014 11:20 AM, Daniel Tryba wrote:
Off to figure out why uac_test incorrectly flags
the onhold process as
needing the nat helper...
Well, nat_uac_test is pretty straightforward, it does what the flags
tell it to do:
http://kamailio.org/docs/modules/stable/modules/nathelper.html#idp1655008
nat_uac_test("18")
so checks 2 and 16 are active:
2 - the "received" test is used: address in Via is compared against source IP
address of signaling
16 - test if the source port is different from the port in Via
U 2014/02/05 13:19:07.820051 109.235.32.40:5060 -> 109.235.36.148:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
109.235.36.148;rport=5060;branch=z9hG4bK6d5.b42bb34512cf1a9aca30c530c393effc.1;i=1.
Via: SIP/2.0/TCP
10.0.3.175:5074;rport=5074;received=109.235.34.226;branch=z9hG4bK-1eb98d43.
Contact: <sip:172.19.162.1;line=pcs-
mp4KWAydWGy3xGygxG5yxRy6uAXsEOdsE1d3xGmwERypxGcSm8HomgIbmPMl9DQK>.
is not natted:
T 2014/02/05 13:19:07.835707 109.235.36.148:5060 -> 109.235.34.226:5074 [AP]
SIP/2.0 200 OK.
Via: SIP/2.0/TCP
10.0.3.175:5074;rport=5074;received=109.235.34.226;branch=z9hG4bK-1eb98d43.
Contact: <sip:172.19.162.1;line=pcs-
mp4KWAydWGy3xGygxG5yxRy6uAXsEOdsE1d3xGmwERypxGcSm8HomgIbmPMl9DQK>.
But this one triggers the nat_uac_test("18") somewhere:
U 2014/02/05 13:19:32.889512 109.235.32.40:5060 -> 109.235.36.148:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
109.235.36.148;rport=5060;branch=z9hG4bK2d2f.4ee703b7d124f96de7b6b643ae82b6af.0;i=1.
Via: SIP/2.0/TCP
10.0.3.175:5074;rport=5074;received=109.235.34.226;branch=z9hG4bK-63ad12f5.
Contact: "Daniel" <sip:172.19.162.1;line=pcs-
mp4KWiTsxRMKxAnsWGZpxry3xGnoxAxtuAxSuA7KEsktxGZKWgQfZD6smqlf9Gttzjy*>.
becomes:
T 2014/02/05 13:19:32.890401 109.235.36.148:5060 -> 109.235.34.226:5074 [AP]
SIP/2.0 200 OK.
Via: SIP/2.0/TCP
10.0.3.175:5074;rport=5074;received=109.235.34.226;branch=z9hG4bK-63ad12f5.
Contact: "Daniel" <sip:172.19.162.1;alias=109.235.32.40~5060~1;line=pcs-
mp4KWiTsxRMKxAnsWGZpxry3xGnoxAxtuAxSuA7KEsktxGZKWgQfZD6smqlf9Gttzjy*>.
From here the contact sent back to 109.235.32.40 contains
alias=109.235.32.40~5060~1 so the requests will not be relayed to the actual
endpoint:
T 2014/02/05 13:19:36.104652 109.235.34.226:5074 -> 109.235.36.148:5060 [A]
INVITE sip:172.19.162.1;alias=109.235.32.40~5060~1;line=pcs-
mp4KWiTsxRMKxAnsWGZpxry3xGn6smqlf9Gttzjy* SIP/2.0.
Via: SIP/2.0/TCP 10.0.3.175:5074;branch=z9hG4bK-6ef0f7c0.
Contact: "klant1" <sip:klant1@10.0.3.175:5074;transport=tcp>.
U 2014/02/05 13:19:36.108198 109.235.36.148:5060 -> 109.235.32.40:5060
INVITE sip:172.19.162.1;alias=109.235.32.40~5060~1;line=pcs-
mp4KWiTsxRMKxAnsWGZpxry3xGn6smqlf9Gttzjy* SIP/2.0.
Via: SIP/2.0/UDP
109.235.36.148;branch=z9hG4bKfc2f.a855b8f452b3127d9384838fd250961b.0;i=1.
Via: SIP/2.0/TCP
10.0.3.175:5074;rport=5074;received=109.235.34.226;branch=z9hG4bK-6ef0f7c0.
Contact: "klant1"
<sip:klant1@10.0.3.175:5074;alias=109.235.34.226~5074~2;transport=tcp>.
U 2014/02/05 13:19:36.110380 109.235.32.40:5060 -> 109.235.36.148:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP
109.235.36.148;branch=z9hG4bKfc2f.a855b8f452b3127d9384838fd250961b.0;i=1;rport=5060.
Via: SIP/2.0/TCP
10.0.3.175:5074;rport=5074;received=109.235.34.226;branch=z9hG4bK-6ef0f7c0.
U 2014/02/05 13:19:36.112998 109.235.32.40:5060 -> 109.235.36.148:5060
SIP/2.0 478 Unresolvable destination (478/SL).
Via: SIP/2.0/UDP
109.235.36.148;branch=z9hG4bKfc2f.a855b8f452b3127d9384838fd250961b.0;i=1;rport=5060.
Via: SIP/2.0/TCP
10.0.3.175:5074;rport=5074;received=109.235.34.226;branch=z9hG4bK-6ef0f7c0.
The only difference between requests/responses to onhold from A is the first
is in a call from B to A. The second one is A to B.
What I do is skip nat_uac_test for the requests and
responses coming
from other proxies' IPs..
That is a solution but breaks the simplicity of the current (public) platform.
Thanks for listening :)
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven
Telefoon: 040 293 8661 - Fax: 040 293 8658
http://www.pocos.nl/ -
http://www.sipo.nl/
K.v.K. Eindhoven 17097024