[Freeswitch-users] ReINVITE failure with ACK+SDP scenario
BNML
bnml at andrexen.com
Tue Jul 2 21:11:40 MSD 2013
Sorry I meant : "I am _now_ able". Thanks you
Le 02/07/2013 19:10, BNML a écrit :
> I am not able to propagate the ACK+SDP (and the INVITE without SDP) to
> the carrier. Thanks !
>
> Le mar. 02 juil. 2013 18:13:40 CEST, Shona McNeill a écrit :
>> Try adding
>>
>> <param name="enable-3pcc" value="proxy"/>
>>
>> to the sip profile.
>>
>> The horror that is "bypass media with proxy-mode 3pcc" should handle ACK+SDP after a no-SDP invite. :-)
>> At the least, it may point the way to what else needs to be added to make it all work.
>>
>>
>> Shona
>>
>>
>>
>>> -----Original Message-----
>>> From: freeswitch-users-bounces at lists.freeswitch.org [mailto:freeswitch-
>>> users-bounces at lists.freeswitch.org] On Behalf Of BNML
>>> Sent: 02 July 2013 16:49
>>> To: FreeSWITCH Users Help
>>> Subject: Re: [Freeswitch-users] ReINVITE failure with ACK+SDP scenario
>>>
>>> I am suspecting a patch on mod_sofia migth be needed in order to
>>> resolve the Late SDP Negotiation in an RE-INVITE scenario to avoir the
>>> one-way audio. I can get involved in writing the patch, if needed.
>>>
>>> Here is the FS console logs along with sip trace
>>> http://pastebin.freeswitch.org/21141
>>>
>>> Le 01/07/2013 14:40, Muhammad Shahzad a écrit :
>>>
>>>
>>> Can you send FS console logs along with sip trace enabled? Just
>>> curious how FS responds to this situation.
>>>
>>> Thank you.
>>>
>>>
>>> On Mon, Jul 1, 2013 at 7:21 PM, BNML <bnml at andrexen.com> wrote:
>>>
>>>
>>> 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> 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
>>> http://www.freeswitchsolutions.com
>>>
>>> FreeSWITCH-powered IP PBX: The CudaTel
>>> Communication Server
>>>
>>>
>>> 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/freeswitc
>>> h-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
>>> Email: shaheryarkh at googlemail.com
>>>
>>>
>>>
>>>
>>> _________________________________________________________________
>>> ________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> FreeSWITCH-powered IP PBX: The CudaTel Communication
>>> Server
>>>
>>>
>>> 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/freeswitc
>>> h-users
>>> http://www.freeswitch.org
>>>
>>>
>>>
>>>
>>> _________________________________________________________________
>>> ________
>>> 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/freeswitc
>>> h-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
>>> Email: 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/freeswitc
>>> h-users
>>> http://www.freeswitch.org
>>>
>>
>>
>>
>> _________________________________________________________________________
>> 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
>
Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users
mailing list