freeswitch reuses RTP port when bridging second call to user
I have a problem relating the handling of a second incoming call to same extension/user. The scenario is this: - call from PSTN comes to freeswitch; freeswitch bridges the call to the identified registered device; call is set up fine (two-way audio) - a second call from the PSTN to the same DID comes to freeswitch; freeswitch bridges the call to the same identified registered device; call has no audio In looking at the traces, the problem stems from the fact that for the second call freeswitch is sending an INVITE offering an SDP with the same source ip and port as the first call. This causes the subsequent INVITE on hold from the phone (which is accepted by the freeswitch) to cause the phone not to send any RTP; meanwhile, the RTP sent from the freeswitch to the phone for the second call is rejected with an ICMP port unreachable since the phone has successfully invited that port on hold. In other words, by re-using the same port for call 1 and call 2, when call 1 is invited on hold the result means no media for call 2. Is this known, or expected behavior? Is this a bug? Has this been fixed in a more recent release (I'm on a very old release) Dave
participants (1)
-
Dave Horton