[SR-Users] Distorted uri / Route header replaces the uri

Abdulaziz Alghosh aziz647 at gmail.com
Fri Oct 12 09:29:39 CEST 2018


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 at 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 at domain.com>;tag=as3b989c5f
To: <sip:yyyyyyyyyyyyy at 192.168.226.132:5060>;tag=1af2c424
Contact: <sip:xxxxxxxxx at 192.168.226.133:5060>
Call-ID: 7ed2ab533d4c43086746d0e620bdff06 at 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 at domain.com>;tag=as3b989c5f
To: <sip:yyyyyyyyy at 192.168.226.132:5060>;tag=1af2c424
Contact: <sip:xxxxxxx at 192.168.226.132:5060>
Call-ID: 7ed2ab533d4c43086746d0e620bdff06 at domain.com
CSeq: 102 ACK
User-Agent: MGW
Content-Length: 0

Thanks in advance for your contribution
Abdulaziz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20181012/195d2c06/attachment.html>


More information about the sr-users mailing list