[Freeswitch-users] ReINVITE failure with ACK+SDP scenario
BNML
bnml at andrexen.com
Mon Jul 1 21:20:45 MSD 2013
Hi,
The problem is that FreeSWITCH doesn't forward Late SDP negotiation in a
RE-INVITE scenario which end up to one way audio.
After testing the option "enable-soa" didn't resolved the issue.
I want to bridge two calls that are already established (I am not
dealing with INVITE but with Re-INVITE) .
That's why inbound-late-negotiation (which is within the dialplan) is
not in the scope of this (I have it activated already).
> When Call B is answered, you should use SDP in 200 OK as basis for
SDP of ACK in Call A. Otherwise you will get one way audio as expect.
Yes. This is the scenario I described at state 4) of the schema.
Thanks
BNML
Le 06/28/2013 07:00 PM, Muhammad Shahzad a écrit :
> I am not sure what you are trying to do here. You said we want to
> originate two calls from your PABX to carrier through FS, i.e.
>
> Call A: PABX -> FS -> Carrier -> User A
> Call B: PABX -> FS -> Carrier -> User B
>
> And then bridge them on FS, such that,
>
> User A <- Carrier <- FS -> Carrier -> User B
>
> I think there are easier ways to achieve this. But anyway in this
> scenario,
>
> Since Call A does not have SDP, which means you are triggering Late
> SDP Negotiation. Make sure you have enabled in sofia profile,
>
> <param name="inbound-late-negotiation" value="true"/>
>
> So, that FS does not Answer it with local SDP. Additionally you may
> need to disable SOA,
>
> <param name="enable-soa" value="false"/>
>
> When 200 OK for Call A arrives (from carrier, through FS to PABX), you
> use it as basis for SDP of INVITE in Call B. That's interesting..
>
> When Call B is answered, you should use SDP in 200 OK as basis for SDP
> of ACK in Call A. Otherwise you will get one way audio as expect.
>
>
> Thank you.
>
>
>
>
> On Fri, Jun 28, 2013 at 6:56 PM, BNML <bnml at andrexen.com
> <mailto:bnml at andrexen.com>> wrote:
>
> 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
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org <mailto:consulting at freeswitch.org>
> http://www.freeswitchsolutions.com
>
>
>
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> <mailto:FreeSWITCH-users at lists.freeswitch.org>
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
>
>
> --
> Mit freundlichen Grüßen
> Muhammad Shahzad
> -----------------------------------
> CISCO Rich Media Communication Specialist (CRMCS)
> CISCO Certified Network Associate (CCNA)
> Cell: +49 176 99 83 10 85
> MSN: shari_786pk at hotmail.com <mailto:shari_786pk at hotmail.com>
> Email: shaheryarkh at googlemail.com <mailto:shaheryarkh at googlemail.com>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
>
>
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130701/4d4412da/attachment-0001.html
Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users
mailing list