[Freeswitch-dev] ReINVITE failure with ACK+SDP scenario
bnml at andrexen.com
Fri Jun 28 20:47:21 MSD 2013
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
It is sending a first INVITE without SDP and it will send the SDP in the
(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.
Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-dev