Anthony Minessale II added a comment - 03/Oct/11 8:49 AM This is unacceptable to answer the phrase "Latest Build" Soon we will begin to close bugs not properly filled out. It very specifically asks for the version string of the GIT revision. You probably have a NAT problem and if you think you have a real bug it's your burden to prove something is not working within FreeSWITCH.  

Yuri Ost added a comment - 03/Oct/11 6:02 PM >This is unacceptable to answer the phrase "Latest Build" >Soon we will begin to close bugs not properly filled out. It very specifically asks for the version string of the GIT revision. Sorry, but console shows: freeswitch@host > version FreeSWITCH Version 1.0.head (git-) I guess what you need is this string (let me know if it's not): cbfe83c..d39b7c6 It comes from: C:\Dev\FS>git fetch remote: Counting objects: 153, done. remote: Compressing objects: 100% (95/95), done. remote: Total 95 (delta 79), reused 0 (delta 0) Unpacking objects: 100% (95/95), done. From git://git.freeswitch.org/freeswitch    cbfe83c..d39b7c6 master -> origin/master >You probably have a NAT problem and if you think you have a real bug it's your burden to prove something is not working within FreeSWITCH. I've rebuild FS using the latest sources (see hash above), just to see if it makes any difference. Unfortunately, there is no any. Test environment: 1. FS, IP = FS.FS.FS.FS 2. Local client A, 1000@domainA , WAN IP = AA.AA.AA.AA 3. Remote client B, 2001@domainB , WAN IP = BB.BB.BB.BB All of the above are all on different static IP and all behind their own NAT routers. Test scenario: 1. Remote SIP client B makes call 2. Call is answered by A, audio is OK 3. Local SIP client A hangs up 4. FS doesn't send BYE message to remote SIP client B, which continues to maintain the call indefinitely. Debugging done using console, running these commands: freeswitch@host >sofia profile internal siptrace on freeswitch@host >sofia profile external siptrace on After local client A hangs up there are messages: recv 410 bytes from udp/[AA.AA.AA.AA]:50401 at 21:55:39.305435:    ------------------------------------------------------------------------    BYE sip: mod_sofia@FS.FS.FS.FS :5060 SIP/2.0    Via: SIP/2.0/UDP AA.AA.AA.AA:50401;rport;branch=z9hG4bKPjiCHKgqFxyWeNk6vfEPh4P9Osf0PfiDYP    Max-Forwards: 70    From: <sip: 1001@AA.AA.AA.AA ;ob>;tag=Bc6x2YDTuG-YYR0bXhCawTEmxLmwDfik    To: "Caller" <sip: 2001@domainA >;tag=2gDU1rtQt2pBc    Call-ID: 341e73b9-68ad-122f-a3a4-c56e4c4aee70    CSeq: 8374 BYE    User-Agent: CSipSimple r1025 / liberty-7    Content-Length: 0    ------------------------------------------------------------------------ 10011-10-03 14:55:39.285404 [NOTICE] sofia.c:573 Hangup sofia/internal/sip: 1001@AA.AA.AA.AA :50401 [CS_HIBERNATE] [NORMAL_CLEARING] send 530 bytes to udp/[AA.AA.AA.AA]:50401 at 21:55:39.575845:    ------------------------------------------------------------------------    SIP/2.0 200 OK    Via: SIP/2.0/UDP AA.AA.AA.AA:50401;rport=50401;branch=z9hG4bKPjiCHKgqFxyWeNk6vfEPh4P9Osf0PfiDYP    From: <sip: 1001@AA.AA.AA.AA ;ob>;tag=Bc6x2YDTuG-YYR0bXhCawTEmxLmwDfik    To: "Caller" <sip: 2001@domainA >;tag=2gDU1rtQt2pBc    Call-ID: 341e73b9-68ad-122f-a3a4-c56e4c4aee70    CSeq: 8374 BYE    User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-    Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE    Supported: timer, precondition, path, replaces    Content-Length: 0    ------------------------------------------------------------------------ 10011-10-03 14:55:39.605891 [NOTICE] switch_ivr_bridge.c:992 Hangup sofia/external/2001@domainB [CS_HIBERNATE] [NORMAL_CLEARING] 10011-10-03 14:55:40.036544 [NOTICE] switch_core_session.c:1367 Session 7 (sofia/external/2001@domainB) Ended 10011-10-03 14:55:40.036544 [NOTICE] switch_core_session.c:1369 Close Channel sofia/external/2001@domainB [CS_DESTROY] 10011-10-03 14:55:40.036544 [NOTICE] switch_core_session.c:1367 Session 8 (sofia/internal/sip: 1001@AA.AA.AA.AA :50401) Ended 10011-10-03 14:55:40.036544 [NOTICE] switch_core_session.c:1369 Close Channel sofia/internal/sip: 1001@AA.AA.AA.AA :50401 [CS_DESTROY] As you can see, there is no BYE message sent to BB.BB.BB.BB address (caller B). Please notice, that the BYE message received form client A contains mangled information about caller B. In this message you see:    To: "Caller" <sip: 2001@domainA >;tag=2gDU1rtQt2pBc It's name (2001) is concatenated with domainA, which is wrong. Client comes from domainB. Caller B actually makes call with this data:    From: "Caller" <sip: 2001@domainB >;tag=3878676791    Contact: <sip: 2001@domainB > The data was replaced / mangled by FS earlier, when FS sent INVITE message to A:    From: "Caller" <sip: 2001@domainA >;tag=2gDU1rtQt2pBc    To: <sip: 1001@AA.AA.AA.AA :50401;ob> Mentioned above replacement doesn't prevent successful call (call was answered, audio was OK), but: 1. It may give you a clue, why FS doesn't send BYE to B 2. It's wrong and should be corrected. Client A should get INVITE request containing proper "From" data. In this example it should be:    From: "Caller" <sip: 2001@domainB >;tag=2gDU1rtQt2pBc BTW, the very same client in the same environment (see above its description), but registered locally, makes similar call and gets BYE request at the end of the call... Bottom line: I don't think it's a NAT problem. FS shuffling caller ID info in the middle of the call and that may cause the result (it doesn't notifies B with BYE message). Finally, not related to this particular issue, but: could you please log time stamps consistently, using the same time zone format? It creates unnecessary troubles to work with e.g. 21:55:39.305435 and then with 14:55:39.285404 (which is essentially the same time)... Usually you log e.g. 10011-10-03 14:55:39.285404, while sofia messages uses a different time zone format (e.g. 21:55:39.305435). Please, pick and use one. Thanks.

Anthony Minessale II added a comment - 03/Oct/11 6:46 PM If you think or don't think you know what the problem is then why are you reporting it here instead of just fixing it and submitting the patch? If you want someone to look at your issue then collect the entire log of the problem as you see it and post it for me to evaluate (not just snippets you find useful, rather the complete log including the sip trace) We did not write the sofia lib so it's not our prerogative to modify the format of the timestamps generated by their traces and to be honest your request sounds rather demanding considering we are volunteering to help you.

Yuri Ost added a comment - 03/Oct/11 11:22 PM I guess the best way to find out is to try it by yourself. If I left something unclear (how to make this simple test) - I'd be glad to clarify. Here is the whole log, that I've collected and have mentioned in my previous post: I hope this will help... I've replaced only IP's and domains (for obvious reasons). AA.AA.AA.AA - WAN IP of A BB.BB.BB.BB - WAN IP of B FS.FS.FS.FS - WAN IP of FS SS.SS.SS.SS - LAN IP of FS recv 980 bytes from udp/[BB.BB.BB.BB]:16146 at 21:55:07.156382:    ------------------------------------------------------------------------    INVITE sip: 1001@domainA :5080 SIP/2.0    Via: SIP/2.0/UDP BB.BB.BB.BB:5135;branch=z9hG4bK002cb00478ece011acb695b75663b160;rport    From: "Caller" <sip: 2001@domainB >;tag=3878676791    To: <sip: 1001@domainA :5080>    Call-ID: 002CB004-78EC-E011-ACB5-95B75663B160@BB.BB.BB.BB    CSeq: 19 INVITE    Contact: <sip: 2001@domainB >    Content-Type: application/sdp    Allow: INVITE, OPTIONS, ACK, BYE, CANCEL, INFO, NOTIFY, MESSAGE, UPDATE    Max-Forwards: 70    Supported: 100rel, replaces, from-change    User-Agent: SIPPER for PhonerLite    P-Preferred-Identity: sip: 2001@domainB    Content-Length: 399    v=0    o=- 3391872544 0 IN IP4 BB.BB.BB.BB    s=SIPPER for PhonerLite    c=IN IP4 BB.BB.BB.BB    t=0 0    m=audio 5062 RTP/AVP 8 0 2 3 97 110 111 9 101    a=rtpmap:8 PCMA/8000    a=rtpmap:0 PCMU/8000    a=rtpmap:2 G726-32/8000    a=rtpmap:3 GSM/8000    a=rtpmap:97 iLBC/8000    a=rtpmap:110 speex/8000    a=rtpmap:111 speex/16000    a=rtpmap:9 G722/8000    a=rtpmap:101 telephone-event/8000    a=fmtp:101 0-16    a=sendrecv    ------------------------------------------------------------------------ send 344 bytes to udp/[BB.BB.BB.BB]:16146 at 21:55:07.156382:    ------------------------------------------------------------------------    SIP/2.0 100 Trying    Via: SIP/2.0/UDP BB.BB.BB.BB:5135;branch=z9hG4bK002cb00478ece011acb695b75663b160;rport=16146    From: "Caller" <sip: 2001@domainB >;tag=3878676791    To: <sip: 1001@domainA :5080>    Call-ID: 002CB004-78EC-E011-ACB5-95B75663B160@BB.BB.BB.BB    CSeq: 19 INVITE    User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-    Content-Length: 0    ------------------------------------------------------------------------ 2011-10-03 14:55:07.136351 [NOTICE] switch_channel.c:911 New Channel sofia/external/2001@domainB [257e423c-8d17-4321-b759-65d167fe666c] 2011-10-03 14:55:07.536963 [INFO] mod_dialplan_xml.c:336 Processing Caller <2001>->1001 in context public 2011-10-03 14:55:08.167927 [NOTICE] switch_ivr.c:1702 Transfer sofia/external/2001@domainB to XML[ 1001@domainA ] 2011-10-03 14:55:08.308141 [INFO] mod_dialplan_xml.c:336 Processing Caller <2001>->1001 in context domainA 2011-10-03 14:55:08.678707 [INFO] switch_ivr_async.c:3107 Bound B-Leg: *1 execute_extension::dx XML features ecordings/2001.2011-10-03-14-55-08.wavch_ivr_async.c:3107 Bound B-Leg: *2 record_session::C:\Program Files\FreeSWITCH 2011-10-03 14:55:08.999197 [INFO] switch_ivr_async.c:3107 Bound B-Leg: *3 execute_extension::cf XML features 2011-10-03 14:55:08.999197 [INFO] switch_ivr_async.c:3107 Bound B-Leg: *4 execute_extension::att_xfer XML features 2011-10-03 14:55:09.249580 [NOTICE] switch_channel.c:911 New Channel sofia/internal/sip: 1001@AA.AA.AA.AA :50401 [07e6ed12-0d06-43ae-80fe-ffef7845c370] send 1274 bytes to udp/[AA.AA.AA.AA]:50401 at 21:55:09.429855:    ------------------------------------------------------------------------    INVITE sip: 1001@AA.AA.AA.AA :50401;ob SIP/2.0    Via: SIP/2.0/UDP FS.FS.FS.FS;rport;branch=z9hG4bKNQ1Xt30UmNmaN    Max-Forwards: 68    From: "Caller" <sip: 2001@domainA >;tag=2gDU1rtQt2pBc    To: <sip: 1001@AA.AA.AA.AA :50401;ob>    Call-ID: 341e73b9-68ad-122f-a3a4-c56e4c4aee70    CSeq: 18503390 INVITE    Contact: <sip: mod_sofia@FS.FS.FS.FS :5060>    User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-    Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE    Supported: timer, precondition, path, replaces    Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer    Privacy: none    Content-Type: application/sdp    Content-Disposition: session    Content-Length: 405    X-FS-Support: update_display    P-Asserted-Identity: "Caller" <sip: 2001@domainA >    v=0    o=- 3391872544 1286953914190554198 IN IP4 BB.BB.BB.BB    s=SIPPER for PhonerLite    c=IN IP4 BB.BB.BB.BB    t=0 0    m=audio 5062 RTP/AVP 8 0 2 3 97 110 111 9 101    a=rtpmap:8 PCMA/8000    a=rtpmap:0 PCMU/8000    a=rtpmap:2 G726-32/8000    a=rtpmap:3 GSM/8000    a=rtpmap:97 iLBC/8000    a=rtpmap:110 speex/8000    a=rtpmap:111 speex/16000    a=rtpmap:9 G722/8000    a=rtpmap:101 telephone-event/8000    a=fmtp:101 0-16    ------------------------------------------------------------------------ recv 295 bytes from udp/[AA.AA.AA.AA]:50401 at 21:55:09.800421:    ------------------------------------------------------------------------    SIP/2.0 100 Trying    Via: SIP/2.0/UDP FS.FS.FS.FS;rport=5060;received=FS.FS.FS.FS;branch=z9hG4bKNQ1Xt30UmNmaN    Call-ID: 341e73b9-68ad-122f-a3a4-c56e4c4aee70    From: "Caller" <sip: 2001@domainA >;tag=2gDU1rtQt2pBc    To: <sip: 1001@AA.AA.AA.AA ;ob>    CSeq: 18503390 INVITE    Content-Length: 0    ------------------------------------------------------------------------ recv 462 bytes from udp/[AA.AA.AA.AA]:50401 at 21:55:09.910589:    ------------------------------------------------------------------------    SIP/2.0 180 Ringing    Via: SIP/2.0/UDP FS.FS.FS.FS;rport=5060;received=FS.FS.FS.FS;branch=z9hG4bKNQ1Xt30UmNmaN    Call-ID: 341e73b9-68ad-122f-a3a4-c56e4c4aee70    From: "Caller" <sip: 2001@domainA >;tag=2gDU1rtQt2pBc    To: <sip: 1001@AA.AA.AA.AA ;ob>;tag=Bc6x2YDTuG-YYR0bXhCawTEmxLmwDfik    CSeq: 18503390 INVITE    Contact: <sip:AA.AA.AA.AA:50401>    Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS    Content-Length: 0    ------------------------------------------------------------------------ 2011-10-03 14:55:09.810436 [NOTICE] sofia.c:5253 Ring-Ready sofia/internal/sip: 1001@AA.AA.AA.AA :50401! send 674 bytes to udp/[BB.BB.BB.BB]:16146 at 21:55:10.221064:    ------------------------------------------------------------------------    SIP/2.0 180 Ringing    Via: SIP/2.0/UDP BB.BB.BB.BB:5135;branch=z9hG4bK002cb00478ece011acb695b75663b160;rport=16146    From: "Caller" <sip: 2001@domainB >;tag=3878676791    To: <sip: 1001@domainA :5080>;tag=0j0rK7aU1tyec    Call-ID: 002CB004-78EC-E011-ACB5-95B75663B160@BB.BB.BB.BB    CSeq: 19 INVITE    Contact: <sip: 1001@BB.BB.BB.BB :5080;transport=udp>    User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-    Accept: application/sdp    Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY    Supported: timer, precondition, path, replaces    Allow-Events: talk, hold, refer    Content-Length: 0    P-Asserted-Identity: "Outbound Call" <sip: 1001@SS.SS.SS.SS >    ------------------------------------------------------------------------ 2011-10-03 14:55:09.960666 [NOTICE] mod_sofia.c:2393 Ring-Ready sofia/external/2001@domainB! 2011-10-03 14:55:09.960666 [NOTICE] switch_ivr_originate.c:481 Ring Ready sofia/external/2001@domainB! --- Ringing... Answered by A: recv 796 bytes from udp/[AA.AA.AA.AA]:50401 at 21:55:19.435140:    ------------------------------------------------------------------------    SIP/2.0 200 OK    Via: SIP/2.0/UDP FS.FS.FS.FS;rport=5060;received=FS.FS.FS.FS;branch=z9hG4bKNQ1Xt30UmNmaN    Call-ID: 341e73b9-68ad-122f-a3a4-c56e4c4aee70    From: "Caller" <sip: 2001@domainA >;tag=2gDU1rtQt2pBc    To: <sip: 1001@AA.AA.AA.AA ;ob>;tag=Bc6x2YDTuG-YYR0bXhCawTEmxLmwDfik    CSeq: 18503390 INVITE    Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS    Contact: <sip:AA.AA.AA.AA:50401>    Supported: replaces, 100rel, timer, norefersub    Content-Type: application/sdp    Content-Length: 257    v=0    o=- 3526667708 3526667709 IN IP4 AA.AA.AA.AA    s=pjmedia    c=IN IP4 AA.AA.AA.AA    t=0 0    a=X-nat:8    m=audio 4000 RTP/AVP 0 101    a=rtcp:4001 IN IP4 AA.AA.AA.AA    a=rtpmap:0 PCMU/8000    a=sendrecv    a=rtpmap:101 telephone-event/8000    a=fmtp:101 0-15    ------------------------------------------------------------------------ send 387 bytes to udp/[AA.AA.AA.AA]:50401 at 21:55:19.635446:    ------------------------------------------------------------------------    ACK sip:AA.AA.AA.AA:50401 SIP/2.0    Via: SIP/2.0/UDP FS.FS.FS.FS;rport;branch=z9hG4bKp0tpvyHZHyaXg    Max-Forwards: 70    From: "Caller" <sip: 2001@domainA >;tag=2gDU1rtQt2pBc    To: <sip: 1001@AA.AA.AA.AA :50401;ob>;tag=Bc6x2YDTuG-YYR0bXhCawTEmxLmwDfik    Call-ID: 341e73b9-68ad-122f-a3a4-c56e4c4aee70    CSeq: 18503390 ACK    Contact: <sip: mod_sofia@FS.FS.FS.FS :5060>    Content-Length: 0    ------------------------------------------------------------------------ 2011-10-03 14:55:19.815721 [NOTICE] sofia.c:5820 Channel [sofia/internal/sip: 1001@AA.AA.AA.AA :50401] has been answered 2011-10-03 14:55:19.815721 [NOTICE] switch_ivr_originate.c:481 Ring Ready sofia/external/2001@domainB! send 952 bytes to udp/[BB.BB.BB.BB]:16146 at 21:55:20.146226:    ------------------------------------------------------------------------    SIP/2.0 200 OK    Via: SIP/2.0/UDP BB.BB.BB.BB:5135;branch=z9hG4bK002cb00478ece011acb695b75663b160;rport=16146    From: "Caller" <sip: 2001@domainB >;tag=3878676791    To: <sip: 1001@domainA :5080>;tag=0j0rK7aU1tyec    Call-ID: 002CB004-78EC-E011-ACB5-95B75663B160@BB.BB.BB.BB    CSeq: 19 INVITE    Contact: <sip: 1001@BB.BB.BB.BB :5080;transport=udp>    User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-    Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY    Supported: timer, precondition, path, replaces    Allow-Events: talk, hold, refer    Content-Type: application/sdp    Content-Disposition: session    Content-Length: 245    P-Asserted-Identity: "Outbound Call" <sip: 1001@SS.SS.SS.SS >    v=0    o=- 3526667708 3526667709 IN IP4 AA.AA.AA.AA    s=pjmedia    c=IN IP4 AA.AA.AA.AA    t=0 0    a=X-nat:8    m=audio 4000 RTP/AVP 0 101    a=rtpmap:0 PCMU/8000    a=rtpmap:101 telephone-event/8000    a=fmtp:101 0-15    a=rtcp:4001 IN IP4 AA.AA.AA.AA    ------------------------------------------------------------------------ 2011-10-03 14:55:19.995996 [NOTICE] switch_ivr.c:709 Channel [sofia/external/2001@domainB] has been answered recv 387 bytes from udp/[BB.BB.BB.BB]:16146 at 21:55:20.236364:    ------------------------------------------------------------------------    ACK sip: 1001@BB.BB.BB.BB :5080;transport=udp SIP/2.0    Via: SIP/2.0/UDP BB.BB.BB.BB:5135;branch=z9hG4bK0094390e78ece011acb695b75663b160;rport    From: "Caller" <sip: 2001@domainB >;tag=3878676791    To: <sip: 1001@domainA :5080>;tag=0j0rK7aU1tyec    Call-ID: 002CB004-78EC-E011-ACB5-95B75663B160@BB.BB.BB.BB    CSeq: 19 ACK    Contact: <sip: 2001@domainB >    Max-Forwards: 70    Content-Length: 0    ------------------------------------------------------------------------ --- Talk. Then A hangs up: recv 410 bytes from udp/[AA.AA.AA.AA]:50401 at 21:55:39.305435:    ------------------------------------------------------------------------    BYE sip: mod_sofia@FS.FS.FS.FS :5060 SIP/2.0    Via: SIP/2.0/UDP AA.AA.AA.AA:50401;rport;branch=z9hG4bKPjiCHKgqFxyWeNk6vfEPh4P9Osf0PfiDYP    Max-Forwards: 70    From: <sip: 1001@AA.AA.AA.AA ;ob>;tag=Bc6x2YDTuG-YYR0bXhCawTEmxLmwDfik    To: "Caller" <sip: 2001@domainA >;tag=2gDU1rtQt2pBc    Call-ID: 341e73b9-68ad-122f-a3a4-c56e4c4aee70    CSeq: 8374 BYE    User-Agent: CSipSimple r1025 / liberty-7    Content-Length: 0    ------------------------------------------------------------------------ 2011-10-03 14:55:39.285404 [NOTICE] sofia.c:573 Hangup sofia/internal/sip: 1001@AA.AA.AA.AA :50401 [CS_HIBERNATE] [NORMAL_CLEARING] send 530 bytes to udp/[AA.AA.AA.AA]:50401 at 21:55:39.575845:    ------------------------------------------------------------------------    SIP/2.0 200 OK    Via: SIP/2.0/UDP AA.AA.AA.AA:50401;rport=50401;branch=z9hG4bKPjiCHKgqFxyWeNk6vfEPh4P9Osf0PfiDYP    From: <sip: 1001@AA.AA.AA.AA ;ob>;tag=Bc6x2YDTuG-YYR0bXhCawTEmxLmwDfik    To: "Caller" <sip: 2001@domainA >;tag=2gDU1rtQt2pBc    Call-ID: 341e73b9-68ad-122f-a3a4-c56e4c4aee70    CSeq: 8374 BYE    User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-    Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE    Supported: timer, precondition, path, replaces    Content-Length: 0    ------------------------------------------------------------------------ 2011-10-03 14:55:39.605891 [NOTICE] switch_ivr_bridge.c:992 Hangup sofia/external/2001@domainB [CS_HIBERNATE] [NORMAL_CLEARING] 2011-10-03 14:55:40.036544 [NOTICE] switch_core_session.c:1367 Session 7 (sofia/external/2001@domainB) Ended 2011-10-03 14:55:40.036544 [NOTICE] switch_core_session.c:1369 Close Channel sofia/external/2001@domainB [CS_DESTROY] 2011-10-03 14:55:40.036544 [NOTICE] switch_core_session.c:1367 Session 8 (sofia/internal/sip: 1001@AA.AA.AA.AA :50401) Ended 2011-10-03 14:55:40.036544 [NOTICE] switch_core_session.c:1369 Close Channel sofia/internal/sip: 1001@AA.AA.AA.AA :50401 [CS_DESTROY] --- Call is ended by A, but B still maintain it. Then B manually hangs up: recv 422 bytes from udp/[BB.BB.BB.BB]:16146 at 21:56:05.505198:    ------------------------------------------------------------------------    BYE sip: 1001@BB.BB.BB.BB :5080;transport=udp SIP/2.0    Via: SIP/2.0/UDP BB.BB.BB.BB:5135;branch=z9hG4bK80080c2978ece011acb695b75663b160;rport    From: "Caller" <sip: 2001@domainB >;tag=3878676791    To: <sip: 1001@domainA :5080>;tag=0j0rK7aU1tyec    Call-ID: 002CB004-78EC-E011-ACB5-95B75663B160@BB.BB.BB.BB    CSeq: 20 BYE    Contact: <sip: 2001@domainB >    Max-Forwards: 70    User-Agent: SIPPER for PhonerLite    Content-Length: 0    ------------------------------------------------------------------------ send 510 bytes to udp/[BB.BB.BB.BB]:16146 at 21:56:05.505198:    ------------------------------------------------------------------------    SIP/2.0 481 Call Does Not Exist    Via: SIP/2.0/UDP BB.BB.BB.BB:5135;branch=z9hG4bK80080c2978ece011acb695b75663b160;rport=16146    From: "Caller" <sip: 2001@domainB >;tag=3878676791    To: <sip: 1001@domainA :5080>;tag=0j0rK7aU1tyec    Call-ID: 002CB004-78EC-E011-ACB5-95B75663B160@BB.BB.BB.BB    CSeq: 20 BYE    User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-    Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY    Supported: timer, precondition, path, replaces    Content-Length: 0    ------------------------------------------------------------------------

Jeff Lenk added a comment - 04/Oct/11 9:21 AM Would you please add the debug info to that log - it would also be easier if you attached the log as a .txt file for easier reading otherwise this list gets awful long.

Anthony Minessale II added a comment - 04/Oct/11 11:02 AM You are assuming that anyone else has this problem. Thousands of people use FreeSWITCH and there are no other reports of a problem fitting this description. I make calls like this every day and I do not have a problem hence why I ask you to provide logs for your problem because you clearly have an edge case that is not easy to reproduce. I asked you to explicitly turn the loglevel to debug and as jeff asked please attach the logs don't post them as the body of a comment. Both these commands: if you are on console: console loglevel debug sofia global siptrace on if you are using fs_cli: /log debug sofia global siptrace on

Yuri Ost added a comment - 04/Oct/11 10:41 PM Please take a look at this log: http://pastebin.com/eFiQpdiV There are two problems: 1. After call was terminated by AAAA, FS never sends BYE message to BBBB 2. FS makes a mess, artificially concatenating users with domains, they don't belong to.

Jeff Lenk added a comment - 05/Oct/11 10:01 AM have you also done a full clean build here? do a rebuild or better yet do a git clean and build again making sure all dependant libs are rebuilt again.

Anthony Minessale II added a comment - 05/Oct/11 2:02 PM You have inbound-bypass-media = true enabled the domains you are talking about are coming from there. This is also information that you should have supplied initially. Please repeat the same exact trace on a fully rebuilt from scratch latest checkout with the following additional command: sofia loglevel all 9

Yuri Ost added a comment - 05/Oct/11 5:38 PM Yes, I know. Dependencies are not properly configured in this project (WS2010 Express), so instead of a simple build I always have to clean it and then build it from the scratch... It takes considerably longer to build, but it looks like I have to do that :( This time I've run: git clean -f git fetch git merge FETCH_HEAD and removed W32 folder with Release build. Then I build the project again. Unfortunately, result is exactly the same as with earlier builds. Git hashes: 1. 114f057..cbfe83c - first post in the thread 2. cbfe83c..d39b7c6 - full log published in previous post 3. f4fa0c0..86efff6 - latest build tested today All tests exhibit the same problems.

Jeff Lenk added a comment - 05/Oct/11 10:04 PM Please attach the information requested - sofia loglevel all 9 Also if you are aware of dependency problems with the vs2010 express build patches will be excepted to fix those. Dependencies for the express build should be the same as for the professional build which I usually test many times per day.

Yuri Ost added a comment - 05/Oct/11 10:32 PM I guess I know where the problem is (thanks to "sofia loglevel all 9" tip). When it's time for FS to send final BYE message, it suddenly decides to send it not to the IP of BBBB, originated the call, but to a host, mentioned in "From" field. I found this line in the log: nua(00F91778): event r_bye 503 DNS Error After that - there is no message sent to BB.BB.BB.BB. Yes, indeed, at the time of these tests, host, used in those fields ( BBBB@domainB ) is not ready to receive calls back. But, even if it was, why FS at the end of the call, after successfully sending 3 messages to address BB.BB.BB.BB, suddenly decides to send that BYE message to a host "domainB"? Is it necessary to change the horses and make DNS lookup at that time? Please take a look at how BYE message is created and particularly, how its destination IP is obtained, and compare it with other messages sent earlier during the call (100 Trying, 180 Ringing, 200 OK). If it's somehow different - could you please make it consistent. BTW, if I set "daomainB" to DNS resolved host CC.CC.CC.CC - FS sends the final BYE message to the "domainB" host (and not to BB.BB.BB.BB as it supposed to): send 613 bytes to udp/[CC.CC.CC.CC]:5060 at 03:11:41.197953:    ------------------------------------------------------------------------    BYE sip: BBBB@domainB SIP/2.0    Via: SIP/2.0/UDP BB.BB.BB.BB:5080;rport;branch=z9hG4bKg9DjyQrQ8DySc    Max-Forwards: 70    From: <sip: AAAA@domainA :5080>;tag=2eBXaFQg8eHeD    To: "Caller" <sip: BBBB@domainB ;tag=3005437281    Call-ID: 008DFA7A-36EE-E011-8ED9-D45294644BED@BB.BB.BB.BB    CSeq: 18599284 BYE    Contact: <sip: AAAA@BB.BB.BB.BB :5080;transport=udp>    User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-    Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY    Supported: timer, precondition, path, replaces    Reason: Q.850;cause=16;text="NORMAL_CLEARING"    Content-Length: 0 Note: Message should be sent to BB.BB.BB.BB IP (correctly mentioned in the "Via" field) and not to CC.CC.CC.CC (IP of the host "domainB"). And again, please look closely at "Contact" field in this message. AAAA doesn't belong to "domainB". Why it's miss-concatenated here?

Anthony Minessale II added a comment - 06/Oct/11 10:34 AM So you are trying to use FreeSWITCH as a proxy here. It's not designed to be a proxy but there are some proxy-like features. Try the following in your diaplan right after you set bypass_media=true <action application="export" data="_nolocal_sip_force_full_from=${sip_full_from}"/> If you still have problems please provide the complete trace as requested. You keep ignoring the requests for the data I ask for until 2 or 3 times. If this continues we will close the issue.

Yuri Ost added a comment - 06/Oct/11 4:48 PM Nope, after adding recommended action the mess still here. 1. FS wants to send BYE message not to the host created the call, but to a different host 2. FS miss-associates users with domains they do not belong to See log here: http://pastebin.com/Fgechib5

Anthony Minessale II added a comment - 07/Oct/11 9:47 AM recv 388 bytes from udp/[BB.BB.BB.BB]:20674 at 20:16:35.799143:    ------------------------------------------------------------------------    ACK sip: AAAA@BB.BB.BB.BB :5080;transport=udp SIP/2.0    Via: SIP/2.0/UDP BB.BB.BB.BB:5135;branch=z9hG4bK80c014c3c5eee0119fdaebf7fbc59e79;rport    From: "CallerB" <sip: BBBB@domainB >;tag=1216799726    To: <sip: AAAA@domainA :5080>;tag=rpZ74BrgD0yNB    Call-ID: 80B2EDBB-C5EE-E011-9FD9-EBF7FBC59E79@BB.BB.BB.BB    CSeq: 4 ACK    Contact: <sip: BBBB@domainB >    Max-Forwards: 70    Content-Length: 0 This packet from your phone contains contact sip: BBBB@domainB the RFC mandates that because of this any further information needs to go to this address. Configure your phone to use BB.BB.BB.BB as the domain name or make domainB resolve to BB.BB.BB.BB In fact it's ridiculous practice to use DNS names in the Contact header of a SIP packet.  

Yuri Ost added a comment - 07/Oct/11 5:12 PM One more time again I've perused RFC 3261: http://www.ietf.org/rfc/rfc3261.txt 1. From this spec the field "Contact" is not a mandatory, as the field "Via" is: - - - - - - - - - - 8.1.1 Generating the Request    A valid SIP request formulated by a UAC MUST, at a minimum, contain    the following header fields: To, From, CSeq, Call-ID, Max-Forwards,    and Via; all of these header fields are mandatory in all SIP    requests. These six header fields are the fundamental building    blocks of a SIP message, as they jointly provide for most of the    critical message routing services including the addressing of    messages, the routing of responses, limiting message propagation,    ordering of messages, and the unique identification of transactions.    These header fields are in addition to the mandatory request line,    which contains the method, Request-URI, and SIP version. - - - - - - - - - - (sorry for long cite, but it explicitly mentions "addressing of messages") 2. Messages send back should use "Via" field, not "Contact" field. It's defined here: - - - - - - - - - - 8.1.1.7 Via    The Via header field indicates the transport used for the transaction    and identifies the location where the response is to be sent. - - - - - - - - - - 3. "Contact" field indeed "can be used to contact", but spec is quite vague on exact details how and when it should be used: - - - - - - - - - - 8.1.1.8 Contact    The Contact header field provides a SIP or SIPS URI that can be used    to contact that specific instance of the UA for subsequent requests. - - - - - - - - - - Now, returning back to FS, FreeSWITCH obviously used "Via" field to contact UAC (which sent first INVITE request). If FS tried to use "Contact" field, it'd fail to send the very first response on that INVITE message. The same is true with regards to other messages, that FS successfully sent to UAC during establishing the call. In all of them FS used "Via" field. It only failed with sending the last message BYE perhaps because it has suddenly decided to use "Contact" field instead of "Via"... Could we make it consistent and use "Via" all the time?

Anthony Minessale II added a comment - 07/Oct/11 5:20 PM Thats why the reply to INVITE works because its' a RESPONSE The last message received from the phone was the ACK which does not have a response. The BYE is a new request and is obligated to send to the last Contact: We cannot change this if we wanted to because its deep in the sofia sip library and besides, it would break things. Why do you not just use the IP in the Contact like everything else in the world?

Yuri Ost added a comment - 07/Oct/11 9:13 PM 1. Because IP could be easily changed. IP could be very dynamic thing. ISP provider may change IP, UAC can easily move to another networks and it would require its reconfiguration all the time. And I'm not talking about current call in the progress here. Without that constant reconfiguration, next time UAC uses a different IP, FreeSWICTH will send BYE message to an obsolete IP. Who needs that? 2. INVITE makes phone call transaction, not BYE message. BYE received from AAAA doesn't create anything new, (no new dialog, nothing). It just completes current truncation in progress - the transaction, created by UAC which has sent the initial INVITE message. And that transaction should be completed with BYE message sent to that UAC, not to any other host.. During the call FS has sent 3 messages to UAC using IP address specified in "Via". It is wrong to send the last, 4th message (BYE) to a potentially different host... I know that fixing bugs in someone else code (Nokia's library) is a PITA. But usually there are other ways to deal with problems. For example, instead of calling nua_bye function, use a function that creates a generic message to send that BYE message. Every library that worth its salt should offer a method to create a new generic message (not sure about NUA though). Or, if there is no such function, bypath the bug with substitution. Right before you call nua_bye function change that "Contact" info to what was saved in "Via" field and return it back right after the function's call is completed. I'm sure, there are other ways of cause. But the problem I see here is with willingness to do the things right... If you want to fix it - everything could be possible. If you don't - I'll have two options: 1) replace "Contact" field in UAC with new IP every time before I make a call; 2) replace FS with another solution, that sends BYE message to UAC properly. I don't want to choose the latter, but the former is not a good answer for me either...

Anthony Minessale II added a comment - 08/Oct/11 11:37 AM It's not a BUG, Its doing exactly what it is supposed to do. Every phone I can think of uses IP in the contact field. The IP is not going to change when you already bound to it. Don't argue SIP implementation with me, go talk to the RFC .....

Yuri Ost added a comment - 10/Oct/11 3:24 PM It is a bug. FS is supposed to communicate with just one host, originated the call. Trying to send BYE message to a different host (not to the originator) is the bug, which leaves the whole call transaction in incomplete state. SIP RFC doesn't require that (sending BYE to a different host). And what about mis-associations, that FS makes? Examples: BBBB@domainA AAAA@SS.SS.SS.SS AAAA@BB.BB.BB.BB

Anthony Minessale II added a comment - 10/Oct/11 3:42 PM The bug is that the UAC (your phone) putting an incorrect contact header in the sip packet that tells the UAS (FreeSWITCH) to contact it at an invalid SIP uri. I have explained it to you multiple times. You may wish it was not this way but it is. The phone must use a valid contact url at all times. What you propose is to intentionally violate the RFC based on your particular problem which you view as a trivial change but it is not. For the last time you have 2 choices: 1) Use the real sip URI in the contact address where FS can reply properly. 2) Make the domainb you put in the contact resolve to the proper sip URI where FS can reply properly.

Yuri Ost added a comment - 10/Oct/11 6:10 PM Id doesn't work. I've set proper "Contact" info, using local number allocated by FS (real sip URI in the contact address). The number BBBB is the next to the number AAAA, the BBBB is calling to. Again, it's a valid account number, that I may call from outside of LAN, very similarly as I call AAAA in this test now. Any user received call form UAC with that "Contact" info can make a call back (if the bug were fixed, of cause, or I have always to remember to say: "please hang up your phone now, over"). As expected (and as I've explained it many times earlier), the final BYE message by FS now was sent to FS itself (not to the UAC, making the call). Message was received and FS responded "SIP/2.0 481 Call Does Not Exist" to itself (obviously). And again, UAC was left in incomplete state... Bottom line: FS should send BYE message to the host, which created the call. FS uses proper "Via" field for sending 3 messages earlier (Trying, Ringing, OK) and the final BYE message should go to the same host too. Otherwise the originator of the call will be left in incomplete state... Any idea why FS mis-associates users with other domains?

Anthony Minessale II added a comment - 11/Oct/11 9:49 AM You did not repeat the trace with all the same debugging enabled so I can't comment on the matter.

Yuri Ost added a comment - 13/Oct/11 4:01 PM I thought that the detailed log, published earlier, was very descriptive, where the bug is. But if it's not enough - here is yet another new log, that shows how FS has mismanages the last BYE message. Even though UAC now uses correct contact information (and SIP client can use it to make call back at any time), FS sends BYE message not to UAC, which originated the call, but to (in this particular case) itself... Then it replies - "SIP/2.0 481 Call Does Not Exist" (see line 922 below). There is no message sent to UAC. Here is the new log: http://pastebin.com/qtyvV7nn Two bugs remain in the FreeSWITCH: 1. FS doesn't send BYE message to UAC, originated the call 2. FS miss-associates users with domains, they don't belong to

Anthony Minessale II added a comment - 13/Oct/11 5:08 PM You are required to reproduce the log every time you claim that it's not working. That is the policy and I do not require any entitlist comments about having to reproduce it again. You are so lost in your fantasy world about how right you are that you are delusional at this point. I believe you have a problem understanding that, IT IS NOT A BUG. The SIP RFC mandates that you MUST set the target to the Contact header. You continue to arrogantly persist despite the fact that I have already closed this bug.... I feel I should bill you for the time it has taken me to respond with increasingly more detailed versions of the same exact explanation over and over that you are 100% wrong. Despite the fact that what you want is not completely illogical, its not legal in the SIP spec...... If you read these citations from the RFC 3261 you will get what you seek and possibly finally understand.......   PAGE 12 Contact contains a SIP or SIPS URI that represents a direct route to    contact Alice, usually composed of a username at a fully qualified    domain name (FQDN). While an FQDN is preferred, many end systems do    not have registered domain names, so IP addresses are permitted.    While the Via header field tells other elements where to send the    response, the Contact header field tells other elements where to send    future requests. 8.1.1.8 Contact    The Contact header field provides a SIP or SIPS URI that can be used    to contact that specific instance of the UA for subsequent requests.    The Contact header field MUST be present and contain exactly one SIP    or SIPS URI in any request that can result in the establishment of a    dialog. For the methods defined in this specification, that includes    only the INVITE request. For these requests, the scope of the    Contact is global. That is, the Contact header field value contains    the URI at which the UA would like to receive requests, and this URI    MUST be valid even if used in subsequent requests outside of any    dialogs.    If the Request-URI or top Route header field value contains a SIPS    URI, the Contact header field MUST contain a SIPS URI as well.    For further information on the Contact header field, see Section    20.10. 12.1.1 UAS behavior    When a UAS responds to a request with a response that establishes a    dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route    header field values from the request into the response (including the    URIs, URI parameters, and any Record-Route header field parameters,    whether they are known or unknown to the UAS) and MUST maintain the    order of those values. The UAS MUST add a Contact header field to    the response. The Contact header field contains an address where the    UAS would like to be contacted for subsequent requests in the dialog    (which includes the ACK for a 2xx response in the case of an INVITE).    Generally, the host portion of this URI is the IP address or FQDN of    the host. The URI provided in the Contact header field MUST be a SIP    or SIPS URI. If the request that initiated the dialog contained a  SIPS URI in the Request-URI or in the top Record-Route header field    value, if there was any, or the Contact header field if there was no    Record-Route header field, the Contact header field in the response    MUST be a SIPS URI. The URI SHOULD have global scope (that is, the    same URI can be used in messages outside this dialog). The same way,    the scope of the URI in the Contact header field of the INVITE is not    limited to this dialog either. It can therefore be used in messages    to the UAC even outside this dialog. 12.1.2 UAC Behavior    When a UAC sends a request that can establish a dialog (such as an    INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e.,    the same SIP URI can be used in messages outside this dialog) in the    Contact header field of the request. If the request has a Request-    URI or a topmost Route header field value with a SIPS URI, the    Contact header field MUST contain a SIPS URI.   When a UAC receives a response that establishes a dialog, it    constructs the state of the dialog. This state MUST be maintained    for the duration of the dialog.    If the request was sent over TLS, and the Request-URI contained a    SIPS URI, the "secure" flag is set to TRUE.    The route set MUST be set to the list of URIs in the Record-Route    header field from the response, taken in reverse order and preserving    all URI parameters. If no Record-Route header field is present in    the response, the route set MUST be set to the empty set. This route    set, even if empty, overrides any pre-existing route set for future    requests in this dialog. The remote target MUST be set to the URI    from the Contact header field of the response. 12.2.1.1 Generating the Request   A UAC SHOULD include a Contact header field in any target refresh    requests within a dialog, and unless there is a need to change it,    the URI SHOULD be the same as used in previous requests within the    dialog. If the "secure" flag is true, that URI MUST be a SIPS URI.    As discussed in Section 12.2.2, a Contact header field in a target    refresh request updates the remote target URI. This allows a UA to    provide a new contact address, should its address change during the    duration of the dialog. 12.2.1.2 Processing the Responses    When a UAC receives a 2xx response to a target refresh request, it    MUST replace the dialog's remote target URI with the URI from the    Contact header field in that response, if present. 12.2.2 UAS Behavior    When a UAS receives a target refresh request, it MUST replace the    dialog's remote target URI with the URI from the Contact header field    in that request, if present. 42.1.0 If you fail to read my citations from the RFC you will never see this and it will be your own fault that you still have a problem: We have a sofia profile paramater that will permanently force all traffic to be set to what was contained in the initial Via header <param name="aggressive-nat-detection" value="true"/>

Yuri Ost added a comment - 13/Oct/11 5:37 PM > We have a sofia profile paramater that will permanently force all traffic to be set to what was contained in the initial Via header <param name="aggressive-nat-detection" value="true"/> It sounds like exactly what we need here: to force all traffic to be set to what was contained in the initial Via header. Here is description of "aggressive-nat-detection" parameter (from http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files): "This will enable NAT mode if the network IP/port from which the request was received differs from the IP/Port combination in the SIP Via: header, or if the Via: header contains the received parameter (regardless of what it contains.)" There is no problem with NAT and "Via" filed. In all cases "Via" field is properly set, using WAN UAC address. How NAT detection setting is related to the fact, that FS properly sends 3 messages (Trying, Ringing, OK) to UAC using "Via" field and then suddenly decides to send the last BYE message using "Contact" field? Am I missing something here?

Anthony Minessale II added a comment - 13/Oct/11 5:52 PM One last time.... "NAT mode" basically means a behavior trigger where the SIP endpoint is forced to ignore the 100 rules I just explained to you and perpetually send any messages to a specific target regardless of the rules. The typical usage is in a NAT scenario where the address in the contact is invalid containing a unreachable address. This mode is automatically triggered when a RFC 1918 addr is detected in the Contact. agressive-nat-detection goes further and looks for things like contact and via not matching. It's not enabled by default because many devices do this on purpose and actually intend the target to switch to the address in the contact. So in your case it's not specifically NAT but the agressive nat detection will pick up on the mismatch between via and contact and force any subsequent packets to be sent to the address in the Via which is what you want. That does not change the fact that your client should not be advertising the wrong address in the Contact field, it should be putting the same host and port that is seen in the via in the contact. If it can't determine it, a proxy should add a record-route header. You are concluding because it sends the 180 RINGING and 200 OK response to INVITE it should naturally send the BYE to the same place but the spec is very specific that the Via is only used to respond to the request. The final response is sent with the 200 OK and your client sends a subsequent ACK with again the wrong contact. When you want to end the call sometime later, the BYE is not a response its a new REQUEST and that REQUEST per the RFC MUST send the BYE to the exact SIP URI provided in the Contact field of the ACK sent by your client. So despite the fact that you have no NAT the parameter will overcome the signaling problem introduced by your Contact fields not being the exact ip:port that will lead back to the client. If you still do not understand I recommend you try elsewhere........

Yuri Ost added a comment - 14/Oct/11 2:46 PM Thank you for clarification what that option does. Uncommenting in "external.xml" file this option helped:     <param name="aggressive-nat-detection" value="true"/> Now UAC, originated direct call to FS, gets BYE message, ending the call. Should I still use followed action in dial plan? <action application="export" data="_nolocal_sip_force_full_from=${sip_full_from}"/> It looks like I can comment it back without any difference (and I'm not using it right now). Is it still needed? I still see lot of user/domain mis-associations. Please find them in detailed logs, provided earlier. So far it's not critical, but may create unexpected problems in a future. Is there any chance to get it fixed?

Anthony Minessale II added a comment - 14/Oct/11 2:57 PM I think now you are mixing up a b2bua and a proxy. The domains only change if they are aligning to the domains you configured your sofia profile to use.

Yuri Ost added a comment - 14/Oct/11 3:19 PM What about these lines (pastebin.com/Fgechib5): 451: BBBB@domainA 561, 710: AAAA@SS.SS.SS.SS 554, 702: AAAA@BB.BB.BB.BB and others... BBBB is not a part of the DomainA, AAAA is not associated with BB.BB.BB.BB address. And final BYE message, sent to UAC by FS, has in its "To" field BBBB@DoaminA again.

Anthony Minessale II added a comment - 14/Oct/11 4:24 PM I saw one place that would have put the domain you are complaining about in the p-asserted because it did not follow that force_full_from hack. I saw one in the 180 that is purely aesthetic for the sake of caller ID display update for phones that only care about the user portion. I changed those in a recent commit but the rest are simply side effects of trying to shoehorn FreeSWITCH into being a proxy. What you need is kamailio or opensips for some of the behaviors you seek.

Yuri Ost added a comment - 15/Oct/11 5:55 PM I'm doing more thorough tests and got couple of related questions. The option suggested to send BYE message back to UAC generates new INVITE messages, sent by FS every minute to some UAC and not to other. For example: 1) External UAC is PhonerLite and it gets INVITE messages every minute. See log: http://pastebin.com/VMCCqRzi In this case internal UAC is "CSipSimple r1038 / liberty-7" 2) External UAC is "CSipSimple r1038 / liberty-7" and it doesn't get any extra INVITE messages form FS. Internal UAC in this case is PhonerLite. Both test calls go via the same dial plan and the same global configuration. I just re-configure aforementioned clients to switch their position related to FS (external vs internal) and then made the calls. Side effect of this behavior is: Call can be terminated with BYE message, received by PhonerLite. On the other hand (scenario #2), FS sends BYE message multiple times, but obviously UAC doesn't get it. Of cause the problem here is with NAT and temporary hole in SIP control channel, closed in a while. It's closed because no messages were sent from FS to UAC during that time (more then 3 min). The question is - why one UAC (PnonerLite) gets kind of ping messages every minute (INVITE in this case) and another UAC (CSipSimple) does not? Haw to make FS to send kind of "ping" message to the UAC in case #2 every minute as well? It will keep control channel alive and allow to get BYE message to terminate the call. I know that FS uses OPTIONS message as a "ping" to keep alive NAT hole. Why in this case it uses INVITE? PhonerLite reacts nicely to that INVITE message so far, but is the INVITE message the best to make pings here?

Anthony Minessale II added a comment - 17/Oct/11 10:07 AM It's sip session timers, the client negotiates it in the sip signalling so both ends need to support it so it will work. One alternate solution for things that are not compat is a very high registration frequency.

Yuri Ost added a comment - 21/Oct/11 3:43 PM Thanks for the hint. It helped to solve the problem. Ironically the UAC, that doesn't support timer (case #1 above), worked well (FS sent reINVITE messages every 60 sec), while the UAC, that does support timer (case #2), did not work (its default and internally hardcoded timeout is 1800 sec, which is way too long to keep NAT hole alive). After I added followed options to "external.xml" file, the latter starts working as well.     <!-- enable session timers: -->     <param name="enable-timer" value="true"/>     <param name="session-timeout" value="120"/> CSipSimple (it does support session timers) accepts new 120 sec value just fine and then use it to periodically (every 60 sec) send UPDATE message to FS. And that works well. Looking at logs I've noticed that with UAC, which doesn't support session timers, FS sends periodic INVITE messages with wrong data in its header field. It sends INVITE with:    Session-Expires: 120;refresher=uac In this case refresher is not UAC, but rather UAS. It's not a critical bug and it still working because UAC doesn't interpret it anyway. But, strictly speaking, it's incorrect. Why FS doesn't use UPDATE message instead or sending INVITE messages every minute? UPDATE message looks a bit more appropriate here and exchange is simpler - UPDATE exchange takes 2 messages (send UPDATE, receive OK/UPDATE), while INVITE requires 3 messages (send INVITE, receive OK/INVITE, sent ACK). It's not a big deal, but I think FS could do it (session timer support) a bit better...

Anthony Minessale II added a comment - 21/Oct/11 5:13 PM the refresher=uac is a request it should either accept it and respond accordingly or change it back to uas or not claim to support it at all by taking timer out of the supported header. using UPDATE is an option in the library but is potential interop issues because many things do not support update, it would require a patch to make a new config option to let you choose....

Yuri Ost added a comment - 24/Oct/11 3:29 PM In the case mentioned UAC doesn't support session timers. Thus it can't change "uac" back to "uas". But nevertheless, FS continue to send re-INVITE with the "refresher=uac" value... is there any chance to see the patch? I'd like to test it.

Anthony Minessale II added a comment - 24/Oct/11 4:13 PM there is no patch, I am saying you would have to write one to expose the functionality.

Auto Admin added a comment - 07/Nov/11 8:17 PM Due to a long period of inactivity (13 or more days), this issue is due to be automatically close within 24 hours. If this issue is not actually resolved, please reopen it and add appropriate comments to help developers fix the issue. Thanks,   Jira Admin

Auto Admin added a comment - 07/Nov/11 8:17 PM Since there has been no change to the status of this issue, it is being closed for inactivity Thanks,   Jira Admin