[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