>> -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 _______________________________________________ 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