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@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@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@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@hotmail.com
Email: shaheryarkh@googlemail.com


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org