[Freeswitch-users] no REINVITE on Blind Transfer with bypass_media

[Humberto Quintana]

>> -You could check the sofia debug for r15332 here:
http://pastebin.freeswitch.org/11008

Phone/Devices: 
The caller is the DID provider's Switch. The callee (which also sends the REFER) is Asterisk 1.4.26.

Testing with other devices(linksys SPA962,Grandstream GXV3000) gathers the same results.



> I did not ask you to send me a ladder diagram.
> I asked you to send me a console trace from FreeSWITCH using latest trunk
> (1.0.4 does not help me)
>
> 1) start FreeSWITCH
> 2) run the cli command: console loglevel debug
> 3) run the cli command: sofia profile internal siptrace on
> 4) reproduce your issue and put the trace on freeswitch pastebin
> http://pastebin.freeswitch.org (login and pass are stated in the auth
> dialog)
>
> Also please answer brian's question. What phones and/or sip devices are
> involved in this call.
>
>
>
> On Wed, Nov 4, 2009 at 3:39 PM, Humberto Quintana wrote:
>
>>
>> Thanks for your time,
>>
>> -The scenario is still the same:
>>
>> Always bypass media.
>> Environment 100% NAT free :-)
>> Call established from A to B through FS. Then...
>> Blind transfer from B to C (Refer-to: C)
>> RTP should go directly between A and C.
>>
>>
>> -With 1.0.4 and 1.0.5pre3, FS actually INVITEs C after receiving the
>> REFER-to:C, BUT there is no 2-way audio. Only RTP from C to A (due to the
>> lack of reINVITE to A, after C answers).
>>
>> Please check SIP diagram here:
>>
>> http://provision.netcelerate.net/ngrep/blindxfer2009-11-04-v1.0.5pre3.html
>>
>>
>> -What it's wrong with r15332 is there is not such call to C. For sure I
>> know SIP is a protocol, may be my description was not clear but this SIP
>> diagram speaks by itself ;-)
>>
>> http://provision.netcelerate.net/ngrep/blindxfer2009-11-04rev15332.html
>>
>>
>> -You could check the sofia debug for r15332 here:
>> http://pastebin.com/m6f2b3836
>>
>>
>> Best regards,
>>
>> Humberto
>>
>>>
>>> I don't know what you are talking about anymore.
>>>
>>> The scenario I had tested is when a call is bridged in bypass_media=true
>>> bridge
>>> and you blind transfer that call back to the dialplan
>>>
>>> as soon as it hits the routing state it will resume media.
>>>
>>>
>>> it has been confirmed to not work and confirmed to have been fixed
>> several
>>> time and if you are still having a problem you must have something
>> blocking
>>> some of your packets or something .
>>>
>>> You have to understand that sip is a protocol and your description is
>>> completely non-standard.
>>> Perhaps you should get a console trace and attach it to a jira. The trace
>>> probably makes more sense to me.
>>>
>>> sofia profile internal siptrace on
>>> console loglevel debug
>>>
>>> reproduce and attach the whole capture.
>>>
>>>
>>>
>>> On Tue, Nov 3, 2009 at 6:05 PM, Humberto Quintana wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> I tried r15332 and set in the sofia profile:
>>>>
>>>> a) bypass_media_after_bridge=true only
>>>> b) bypass_media_after_bridge=true, param name="media-option"
>>>> value="resume-media-on-hold"/>
>>>>
>>>>
>>>> In both cases FS is hanging up the initial call (A to FS) after
>> accepting
>>>> the REFER to C:
>>>>
>>>> A <- reINVITE with FS' SDP <- FS
>>>> A -> 200 -> FS
>>>> A <- ACK <- FS
>>>> A <- BYE <- FS
>>>>
>>>> The call to C is not even tried.
>>>>
>>>> I found this line is the logs that could give some idea:
>>>>
>>>> 2009-11-03 18:29:41.280707 [NOTICE] mod_sofia.c:733 Hangup
>>>> sofia/external/514xxxxxx at a.b.c.d [CS_ROUTING]
>> [RECOVERY_ON_TIMER_EXPIRE]
>>>> after sending the ACK for the reINVITE
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>> Humberto
>>>>
>>>>>please try r15326
>>>>>I think i have it working.
>>>>>
>>>>>I recommend for optimal results you set bypass_media_after_bridge=true
>>>>>either as a global or in your DP in place of bypass_media=true
>>>>>
>>>>>
>>>>>On Mon, Nov 2, 2009 at 4:30 PM, Humberto Quintana
>>>> hotmail.com>wrote:
>>>>>
>>>>>> Hi Mike,
>>>>>>
>>>>>> I re-tried with trunk rev 15319 but I got almost the same behavior:
>>>> There
>>>>>> is now a reINVITE (with FS' SDP) going to A when the REFER is
>> accepted.
>>>> But
>>>>>> still there is no reINVITE for A (with C's SDP) after the call from FS
>>>> to C
>>>>>> is established.
>>>>>>
>>>>>> Anyway, we decided for now to do a different implementation but if you
>>>> want
>>>>>> to explore more in this issue count me in ;-)
>>>>>>
>>>>>>
>>>>>> Thank you very much!
>>>>>>
>>>>>> Humberto
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
 		 	   		  
_________________________________________________________________
Ready. Set. Get a great deal on Windows 7. See fantastic deals on Windows 7 now
http://go.microsoft.com/?linkid=9691818