Actually, the problem is - after several seconds the call is loosing audio from PL to CSS.
Quote:Initiating calls from CSS to PhonerLite is exactly as you described. CSS sends some codecs and PhonerLite answers with all codecs that are supported by both of them - that is normal behavior. After that CSS sends a re-INVITE with only one codec. I have a call with media in both directions - no problems at all here.
No problems here at this time too. There is audio from and to CSS, in both direction. But just in a couple of seconds, PL suddenly sends "back-INVITE" with full set of codecs, and at that time CSS looses its ability to convey audio to PH. The audio from PL to CSS continue to work. May be it's a coincidence or may be it's the actual cause of braking audio from CSS to PL.
Again, all my phones (and SIP switch) are located on their own respective LAN's (behind NAT routers) offering correct WAN IP's in their SDP. I was able to maintain audio from both directions for a long time before. And I can do it now if I use the case 1 from my 1st post:
Quote:Now, if I make call in opposite direction (from PL to CSS) there are 2 cases:
1. I pick up CSS within next 2 sec of ringing (time is approximate here), the audio between two parties is always OK
2. I pick up CSS after that time, there is no audio from PL to CSS. The audio from CSS to PL is always OK though.
The weird thing is - there is a similar (about first 2 sec) interval that is important to make the audio work or not too. It may be related or may be not. I mentioned it just in case if it helps.
But let's focus on the call from CSS to PL first and the problem of loosing audio from CSS to PL after several seconds of initially successful call.