Hello,
if I didn't mixed the order of nodes with their IP addresses, then the
ACK is having the wrong address.
ACK being a request within dialog, it must have in R-URI the address
(URI) that was set by the callee, however, in no way the IP of the
dispatcher. So there is something in the path of sip signaling that is
breaking the Contact of the 200ok.
It could be that some node is using mistakenly fix_nated_contact() when
not being the first hop after NAT router. It is anyhow recommended to
use set_contact_alias() together with handle_ruri_alias() (see default
config for v5.1.x on how these are used).
Cheers,
Daniel
On 12.10.18 09:29, Abdulaziz Alghosh wrote:
Greetings,
in order to upgrade kamailio server from 3.0.3 to 5.1.4 version, I am
conducting test calls and it is not completelly successful. The main
components I have are:
1- Media Gateway (Asterisk) : 192.168.226.133
2- Signalling Gateway (Kamailio 5.1.4) 192.168.226.132
3- Global Dispatcher (Kamailio 3.0.3 in front of the Signalling
Gateway.) : 192.168.226.130
Both caller and callee have the dispatcher's IP as a proxy and their
registration requests is passed to be registered at the Signalling
Gateway (Kamailio 5.1.4) and saved on the MySQL server. The caller
reaches the callee properly, who in its turn answeres the call and
sends the OK msg to the caller who gets it. Unfortunately, when the
caller sends the ACK for this INVITE to the callee, the ACK does not
reach the callee because it is trapped by the dispatcher at the last
stage because the uri was dropped and the Route header was used
instead. This behaviour is abnormal since as I know the Route header
should be converted into a Via header and the uri stays untouchable.
The ACK was looped into the dispatcher itself .i.e. the dispatcher
sent it to itself adding always the via header ""Via: SIP/2.0/UDP
192.168.226.130;branch=0"" endlessly.
Once again, here is an example of the ACK before the dispatcher and
how the dispatcher forwards the ACK afterwards.
the supposed path is as following:
caller --> GDP--> SGW --> MGW--> SGW --> GDP --> callee
Although the GDP (before the calle after the SGW) received the uri
well from SGW inside the ACK as it appears below:
ACK
sip:yyyyyyyyyyyy@192.168.226.130:5060;rinstance=1608f7c153f40093;transport=UDP
SIP/2.0
Record-Route: <sip:192.168.226.132;lr=on;ftag=as3b989c5f>
Via: SIP/2.0/UDP
192.168.226.132;branch=z9hG4bK136f.1e8349c235fff01ee1849f3456f8868a.0
Via: SIP/2.0/UDP 192.168.226.133:5060;rport=5060;branch=z9hG4bK34871fe9
Route: <sip:192.168.226.130;lr;ftag=as3b989c5f;did=d5b.87890dc6>
Max-Forwards: 69
From: "xxxxxxxxxxxxxx" <sip:xxxxxxxxxxxx@domain.com
<mailto:sip%3Axxxxxxxxxxxx@domain.com>>;tag=as3b989c5f
To: <sip:yyyyyyyyyyyyy@192.168.226.132:5060
<http://sip:yyyyyyyyyyyyy@192.168.226.132:5060>>;tag=1af2c424
Contact: <sip:xxxxxxxxx@192.168.226.133:5060
<http://sip:xxxxxxxxx@192.168.226.133:5060>>
Call-ID: 7ed2ab533d4c43086746d0e620bdff06(a)domain.com
<mailto:7ed2ab533d4c43086746d0e620bdff06@domain.com>
CSeq: 102 ACK
User-Agent: MGW
Content-Length: 0
The global dipstacher (GDP) has used the Route header (which has no
R-URI yyyyyyyyy) instead of the uri:
ACK sip:192.168.226.130;lr;ftag=as3b989c5f;did=d5b.87890dc6 SIP/2.0
Record-Route: <sip:192.168.226.132;lr=on;ftag=as3b989c5f>
Via: SIP/2.0/UDP 192.168.226.130;branch=0
Via: SIP/2.0/UDP
192.168.226.132;rport=5060;branch=z9hG4bK136f.1e8349c235fff01ee1849f3456f8868a.0
Via: SIP/2.0/UDP 192.168.226.133:5060;rport=5060;branch=z9hG4bK34871fe9
Max-Forwards: 68
From: "xxxxxxxxxx" <sip:xxxxxxxxxxx@domain.com
<mailto:sip%3Axxxxxxxxxxx@domain.com>>;tag=as3b989c5f
To: <sip:yyyyyyyyy@192.168.226.132:5060
<http://sip:yyyyyyyyy@192.168.226.132:5060>>;tag=1af2c424
Contact: <sip:xxxxxxx@192.168.226.132:5060
<http://sip:xxxxxxx@192.168.226.132:5060>>
Call-ID: 7ed2ab533d4c43086746d0e620bdff06(a)domain.com
<mailto:7ed2ab533d4c43086746d0e620bdff06@domain.com>
CSeq: 102 ACK
User-Agent: MGW
Content-Length: 0
Thanks in advance for your contribution
Abdulaziz
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla --
www.asipto.com
www.twitter.com/miconda --
www.linkedin.com/in/miconda
Kamailio World Conference --
www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin --
www.asipto.com