In wireshark, there are 2 fields - Source and
Destination. I am
curious if there are variables in Kamailio which can show me those values.
System:
MYIP - IP of kamailio
sip.mydomain.com <http://sip.mydomain.com> - address of kamailio
User (Imsdroid for Android) ->Kamailio->Asterisk->Kamailio (same)
->Other user.
Problem - register, voice, video, and ring are OK, but ACK and BYE are
going in dead loop - and this happens may be around in 50% of cases -
not in all cases.
If I am using other client (like hardware SIP phones), then I have no
problems, but it is really hard to find some client for Android which
supports video with Kamailio.
To solve problem, I made one function in Kamailio.cfg - ACKBYE, which
is called only within dialog. And within dialog is called in main route.
route[ACKBYE] {
#!ifdef WITH_MYFORWARD
xlog("SCRIPT: AckBye $td;$si;$du;$dd\n");
if((($td=="sip.mydomain.com
<http://sip.mydomain.com>")||($td=="MYIP"))&&($si=="MYIP")){
$du=$sht(forw=>$ft);
xlog("SCRIPT: AckBye2 $td;$si;$du\n");
return;
}
#!endif
return;
}
Of cource I have
if(is_method("INVITE")){
ds_select_dst("1","4");
$sht(forw=>$ft)=$du;
}
This worked for long time. But then we updated client (libraries etc),
and problem appeared again - from time to time. Calls between 2 same
clients can pass 2 or 5 times, and then problem appear.
Before - $td and $si showed destination and source but now there is
difference:
ERROR: <script>: SCRIPT: AckBye 192.168.2.251;MYIP;<null>;<null>
$td in this case show destination, which is correct, but in wireshark,
destination and source = MYIP.
ACK sip:MYIP;lr=on;nat=yes SIP/2.0
Via: SIP/2.0/UDP MYIP;branch=z9hG4bKcydzigwkX
Via: SIP/2.0/UDP MYIP;rport=5060;branch=z9hG4bKcydzigwkX
............................................
Via: SIP/2.0/UDP MYIP;rport=5060;branch=z9hG4bKcydzigwkX
Via: SIP/2.0/UDP 192.168.2.105:44794;branch=z9hG4bK338581244;rport=44794
From: <sip:11171@sip.MYDOMAIN.com
<mailto:sip%3A11171@sip.MYDOMAIN.com>>;tag=1687441663
To: <sip:11175@192.168.2.251
<mailto:sip%3A11175@192.168.2.251>>;tag=as13c57096
Contact:
<sip:11171@MYIP:5060;transport=udp>;+g.oma.sip-im;language="en,fr";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Call-ID: 4026cd88-aab9-19db-dfbe-1510baafdbb3
CSeq: 473985105 ACK
Content-Length: 0
Max-Forwards: 0
Proxy-Authorization: Digest
username="11171",realm="sip.stribogkonsult.com
<http://sip.stribogkonsult.com>",nonce="T2NZUU9jWCWxMUHSQweHXVQppHS8iFhd",uri="sip:11175@MYIP:5060",response="c5a95942af1502c208fa05d34c405907",algorithm=MD5
Accept-Contact:
*;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel
Allow: INVITE, ACK, CANCEL, BYE, MESSAGE, OPTIONS, NOTIFY, PRACK,
UPDATE, REFER
Privacy: none
P-Access-Network-Info: ADSL;utran-cell-id-3gpp=00000000
User-Agent: IM-client/OMA1.0 android-ngn-stack/v2.0.453 (doubango r653)
I suspect the client messes the Record-Route/Route set -- the ACK R-URI
shows a Route address, like there was a strict router. You have to
capture all the messages for such call (from initial INVITE to ACK) and
send them over. ngrep is a tool convenient for that, to get it directly
text suitable for sending over email.
Cheers,
Daniel
--
Daniel-Constantin Mierla
Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany