Trying to make a call from CSipSimple (CSS) client via FreeSWITCH (FS) to PhonerLite (PL). There is no audio and call is terminated by FS. Log shows:
1. INVITE (authorized) is sent from CSS via FS to PL
2. Call was answered by PL and OK/INVITE is sent via FS to CSS
3. CSS sends new INVOTE, now with SDP containing only one codec - PCMU
6. PL replies OK/INVITE with SDP containing only one codec - PCMU

Up until now everything looks normal. But suddenly PL sends new INVITE (where "from"/"to" are reversed) with full set of codecs in SDP again and it breaks the call. There is no audio. PL indicates: "in:---, out:u-Law". CSS doesn't respond to the 6 new INVITE messages sent by FS and FS eventually terminates the call by reason [CS_HIBERNATE]...

Question - why after codec was successfully negotiated, PL suddenly sends its own INVITE message, now containing full set of codecs in SDP? Is it necessary?

Running PL v2.08

NAT is involved (as always).
Here is log, collected from FreeSWITCH:
http://pastebin.com/hFvkD4PN

I hope you understand, that for security reasons I'd prefer do not disclose my IP's within Wiresharks log. But I'd like to provide you with data collected during some tests.

I've just made test call from CSS (CSipSimple) to PL (PhonerLite). After taking the call for several seconds there was silence (no audio). Then, in approximately 3 sec I start to hear audio. Here is the log, connected with Wireshark (watch for port numbers specified after ':'):

00:00 - INVITE, CSS -> PL. SDP:m=4002, many codecs. m=rtcp:4003
00:08 - OK, PL -> CSS. SDP::m=5062, many codecs
00:08 - PL:5063 -> CSS:4003. RTCP - Source description
00:08 - PL:5062 -> CSS:4002. RTP - Unknown RTP version
00:08 - PL:5062 -> CSS:4002. RTP - PT=ITU-T G711 PCMU
00:08 - PL:5062 -> CSS:4002. RTP - PT=ITU-T G711 PCMU
...
PL continues to send RTP packets to CSS, but there is no any messages sent back from CSS to PL
00:09 - INVITE, CSS -> PL. SDP:m=4002, one codec PCMU, m=rtcp:4003
00:09 - OK, PL -> CSS. SDP:m=5062, one codec PCMU
00:09 - PL:5062 -> CSS:4002. RTP - PT=ITU-T G711 PCMU
00:08 - PL:5062 -> CSS:4002. RTP - PT=ITU-T G711 PCMU
...
PL continues to send RTP packets to CSS, but there is no any messages sent back from CSS to PL
00:11 - INVITE, PL -> CSS. SDP:m=5135, many codecs. m=rtcp:5135
first two RTP packets from CSS to PL:
00:11 - CSS:4002 -> PL:5060. RTP - PT=GSM 06.10
00:11 - CSS:4002 -> PL:5060. RTP - PT=GSM 06.10
00:11 - PL:5060 -> CSS:4002. RTP - PT=ITU-T G711 PCMU
00:11 - CSS:4002 -> PL:5060. RTP - PT=GSM 06.10
00:11 - PL:5060 -> CSS:4002. RTP - PT=ITU-T G711 PCMU
00:11 - CSS:4002 -> PL:5060. RTP - PT=GSM 06.10
00:11 - PL:5060 -> CSS:4002. RTP - PT=ITU-T G711 PCMU
00:11 - OK, CSS -> PL. SDP:m=4002, one codec GSM, m=rtcp:4003
00:11 - PL:5060 -> CSS:4002. RTP - Unknown RTP version
00:11 - PL:5060 -> CSS:4002. RTP - PT=GSM 06.10
00:11 - CSS:4002 -> PL:5060. RTP - PT=GSM 06.10
00:11 - PL:5060 -> CSS:4002. RTP - PT=GSM 06.10
00:11 - CSS:4002 -> PL:5060. RTP - PT=GSM 06.10
...
Audio is working since that.
(some details about SDP content you may find in my log, previously mentioned in this thread)

Weird things about it:
1. CSS offers it's usual RTP port 4002, but it doesn't not reply from it for several seconds after the call was answered.
2. In 3 sec PL sends its own INVITE message (offering set of its codecs) and it changes its RTP port form 5062 to 5135 (which will be not used at all, BTW). Only after that moment CSS starts sending its first RTP packets to PL... Watch for the port number that it sends its packets to - it's 5060 (not 5062)! Where this port (5060) comes from? Nevertheless, PL starts to sending RTP packets from this port (5060) back to CSS (4002).
3. Then CSS sends its OK, containing only one codec (GSM, previous codec was PCMU, BTW)
4. Only at that point the audio starts working fine

Questions:
1. Why after 3 sec CSS starts sending RTP to PL:5060 and not to its port 5062? May be it was tried, but 5062 was blocked in NAT router?
2. Why CSS in 3 sec suddenly switches to port 5060 to send RTP packets? Where is comes from? PL sends in its SDP port 5062 first and then it changes it to 5135 (and both were never used) and later it looks like it accepts RTP on port 5060?
3. Do those "Unknown RTP version" packets mean anything?

It's all very strange...

Thank you for the explanations. It made clear a lot of things. But some questions still remain:

I'm watching RTP ports very closely now and see, that when PL launches, it sets in router (via UPnP) NAT rule: External port: 5135  (UDP). Internal port: 5060.

Now, when I make a call PL initially replies to CSS (OK/INVITE message) with SDP: "m: audio 5062 RTP". It makes CSS to send RTP packets to port 5062 (currently blocked by NAT router). That's why we don't see any RTP plackets coming. Reply to the second INVITE (where there is only one codec set) does the same. PL tells to use port 5062 for audio stream...

In several seconds PL sends to CSS its own INVITE message. And interestingly enough, this time it offers port 5135 as its audio port. CSS starts sending packages to 5060 (via external NAT port 5135). As a result, audio starts working OK now.

So, the question is:
Why PL, after setting NAT rule via UPnP to translate external port 5135 into its internal port 5060, initially replies in OK/INVITE SDP offering port 5062 and not 5135?

Again (just for clarification), this case happens when:
a) there is no STUN server assigned
b) in Network configuration UPnP NAT option is checked

Your are right. UPnP isn't used for incoming connections. I fixed that in the beta version now. Please download this beta version from www.phonerlite.de and try again. Please tell me, if it works now.

Couple of more thoughts...

If PL wants to recover after several seconds of not receiving audio stream and it sends its own re-INVITE message with different RTP port in it, I think it's reasonable to expect, that before sending this request, it sets a new NAT rule, that opens the new public port and redirects it to itself.

Second, why PL uses (I think) hardcoded port 5135? IMHO it'd be better to allow me to set that port in "siper.ini" file. For example you may offer option RTPoverSIPFallbackPort, where I can set fallback port number (default: 5135), or better yet, a range of ports. E.g.:
RTPoverSIPFallback=15213,16000-16005
And BTW, the same approach could apply for the initial RTP port too. For example:
RTPPort=5062,5063,28010-28016

Have you had any chance to checked it?

It's much better now. Problem is fixed in v2.09.
Thanks a lot!