<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Greetings,</div><div><br></div><div>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:</div><div>1- Media Gateway (Asterisk) :
192.168.226.133

</div><div>2- Signalling Gateway (Kamailio 5.1.4) 
192.168.226.132

</div><div>3- Global Dispatcher (Kamailio 3.0.3 in front of the 
Signalling Gateway.) 
: 192.168.226.130

</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>Once again, here is an example of the ACK before the dispatcher and how the dispatcher forwards the ACK afterwards.</div><div><br></div><div>the supposed path is as following:</div><div>caller --> GDP--> SGW --> MGW--> SGW --> GDP --> callee</div><div><br></div><div>Although the GDP (before the calle after the SGW) received the uri well from SGW inside the ACK as it appears below:</div><div><br></div><div>ACK sip:yyyyyyyyyyyy@192.168.226.130:5060;rinstance=1608f7c153f40093;transport=UDP SIP/2.0<br>Record-Route: <sip:192.168.226.132;lr=on;ftag=as3b989c5f><br>Via: SIP/2.0/UDP 192.168.226.132;branch=z9hG4bK136f.1e8349c235fff01ee1849f3456f8868a.0<br>Via: SIP/2.0/UDP 192.168.226.133:5060;rport=5060;branch=z9hG4bK34871fe9<br>Route: <sip:192.168.226.130;lr;ftag=as3b989c5f;did=d5b.87890dc6><br>Max-Forwards: 69<br>From: "xxxxxxxxxxxxxx" <<a href="mailto:sip%3Axxxxxxxxxxxx@domain.com" target="_blank">sip:xxxxxxxxxxxx@domain.com</a>>;tag=as3b989c5f<br>To: <<a href="http://sip:yyyyyyyyyyyyy@192.168.226.132:5060" target="_blank">sip:yyyyyyyyyyyyy@192.168.226.132:5060</a>>;tag=1af2c424<br>Contact: <<a href="http://sip:xxxxxxxxx@192.168.226.133:5060" target="_blank">sip:xxxxxxxxx@192.168.226.133:5060</a>><br>Call-ID: <a href="mailto:7ed2ab533d4c43086746d0e620bdff06@domain.com" target="_blank">7ed2ab533d4c43086746d0e620bdff06@domain.com</a><br>CSeq: 102 ACK<br>User-Agent: MGW <br>Content-Length: 0</div><div><br></div><div>The global dipstacher (GDP) has used the Route header (which has no R-URI yyyyyyyyy) 
instead of the uri:</div><div><br></div><div>ACK sip:192.168.226.130;lr;ftag=as3b989c5f;did=d5b.87890dc6 SIP/2.0<br>Record-Route: <sip:192.168.226.132;lr=on;ftag=as3b989c5f><br>Via: SIP/2.0/UDP 192.168.226.130;branch=0<br>Via: SIP/2.0/UDP 192.168.226.132;rport=5060;branch=z9hG4bK136f.1e8349c235fff01ee1849f3456f8868a.0<br>Via: SIP/2.0/UDP 192.168.226.133:5060;rport=5060;branch=z9hG4bK34871fe9<br>Max-Forwards: 68<br>From: "xxxxxxxxxx" <<a href="mailto:sip%3Axxxxxxxxxxx@domain.com" target="_blank">sip:xxxxxxxxxxx@domain.com</a>>;tag=as3b989c5f<br>To: <<a href="http://sip:yyyyyyyyy@192.168.226.132:5060" target="_blank">sip:yyyyyyyyy@192.168.226.132:5060</a>>;tag=1af2c424<br>Contact: <<a href="http://sip:xxxxxxx@192.168.226.132:5060" target="_blank">sip:xxxxxxx@192.168.226.132:5060</a>><br>Call-ID: <a href="mailto:7ed2ab533d4c43086746d0e620bdff06@domain.com" target="_blank">7ed2ab533d4c43086746d0e620bdff06@domain.com</a><br>CSeq: 102 ACK<br>User-Agent: MGW<br>Content-Length: 0</div><div><br></div><div>Thanks in advance for your contribution <br></div><div>Abdulaziz<br></div></div></div></div></div></div>