[Freeswitch-dev] ReINVITE failure with ACK+SDP scenario
Hi all, I am having trouble with a transfert failure in a special scenario which i wasn't able to find documentation or configuration option solving it. I have a PBX creating two outbound call, it want to bridge them on the FreeSWITCH. It is sending a first INVITE without SDP and it will send the SDP in the ACK. (This is not breaking RFC3261 but I admit rarely seen scenario. http://tools.ietf.org/html/rfc3261#section-13.2.1 : "The UAC MAY choose to add a message body to the INVITE.". Looking at this scenario there is, indeed, at least one interesting scenario where it can helps avoiding creating another useless Re-INVITE transaction, see below) For the second call it is sending a re-invite with SDP. FreeSWITCH will understand and forward (because of "bypass_media") the second Re-INVITE but does never forward the first Re-INVITE (The one without SDP in the INVITE but in the ACK) to carrier, so this will end up in one-way-audio. A little schema to help : PBX FREESWITCH COMMENT 1) INVITE (a-leg) [THERE IS NO SDP] 2) 200 OK (fs-a-leg)[FreeSWITCH answer with the SDP information before any media update occurs, but my PBX is now aware of media informations] 3) INVITE+SDP (b-leg) [This is b-leg updated media information with previous 200 OK (fs-a-leg)] 4) 200 OK (fs-b-leg)[My PBX updated media and has b-leg freeswitch media information that it will send in the ACK+SDP to finalize the both-legs Re-INVITE] 5) ACK (b-leg) [Acknoledgement of b-leg Re-INVITE transaction] 6) ACK+SDP (a-leg) [ *** problem *** it assume FreeSWITCH will update media information and forward to the carrier which it won't] The solution i imagine is FreeSWITCH SHOULD trigger a Re-INVITE either for the a-leg at INVITE (without SDP in "1") receiption (and update media information when receiving the ACK+SDP) _OR_ create a Re-INVITE transaction at "6" when receiving ACK+SDP. One way or another, I am supposing FreeSWITCH refuse to forward the INVITE without SDP at first maybe because of carrier compatibility ? If not, this seems the way to go. Has anyone faced such a scenario ? Am I rigth assuming a patch is needed ? If yes, any suggestions are welcome. Thanks you BNML
participants (1)
-
BNML