Hello,

On 3/16/12 4:43 PM, Stoyan Mihaylov wrote:
In wireshark, there are 2 fields - Source and Destination. I am curious if there are variables in Kamailio which can show me those values.

are you looking for $si (source ip) and $Ri (received ip)?
System:
MYIP - IP of kamailio
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")||($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>;tag=1687441663
To: <sip:11175@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",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
http://www.asipto.com/index.php/kamailio-advanced-training/