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

2009-11-05 Thread 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/514xx 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:h

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

2009-11-04 Thread Brian West 
What phones are you using?  I do this exact same scenario without a  
problem over and over testing with anthm.  So I would like to know  
what phones you're using.

/b

On 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/514xx 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
>>>
>>>
>>> _
>>> Windows Live: Friends get your Flickr, Yelp, and Digg updates when  
>>> they
>>> e-mail you.
>>> http://go.microsoft.com/?linkid=9691817
>>> ___
>>> 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
>>>
>>
>>
>>
>> --
>> Anthony Minessale II
>>
>> _
>> Ready. Set. Get a great deal on Windows 7. See fantastic deals on  
>> Windows 7 now
>> http://go.microsoft.com/?linkid=9691818
>   
> _
> Windows Live: Make it easier for your friends to see what you’re up  
> to on Facebook.
> http://go.microsoft.com/?linkid=9691816
> ___
> 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

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

2009-11-04 Thread Humberto Quintana 

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/514xx 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
>>
>>
>> _
>> Windows Live: Friends get your Flickr, Yelp, and Digg updates when they
>> e-mail you.
>> http://go.microsoft.com/?linkid=9691817
>> ___
>> 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
>>
>
>
>
> --
> Anthony Minessale II
>
> _
> Ready. Set. Get a great deal on Windows 7. See fantastic deals on Windows 7 
> now
> http://go.microsoft.com/?linkid=9691818
  
_
Windows Live: Make it easier for your friends to see what you’re up to on 
Facebook.
http://go.microsoft.com/?linkid=9691816
___
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

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

2009-11-03 Thread Humberto Quintana 

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/514xxx...@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

  
_
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail 
you.
http://go.microsoft.com/?linkid=9691817
___
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

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

2009-11-03 Thread Anthony Minessale 
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/514xxx...@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
>
>
> _
> Windows Live: Friends get your Flickr, Yelp, and Digg updates when they
> e-mail you.
> http://go.microsoft.com/?linkid=9691817
> ___
> 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
>



-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_miness...@hotmail.com 
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org 
iax:gu...@conference.freeswitch.org/888
googletalk:conf+...@conference.freeswitch.org
pstn:213-799-1400
___
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

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

2009-11-03 Thread Brian West 
Do you have ANY nat involved?

/b

On Nov 3, 2009, at 6:05 PM, Humberto Quintana wrote:

> 2009-11-03 18:29:41.280707 [NOTICE] mod_sofia.c:733 Hangup sofia/ 
> external/514xxx...@a.b.c.d [CS_ROUTING] [RECOVERY_ON_TIMER_EXPIRE]
> after sending the ACK for the reINVITE


___
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

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

2009-11-02 Thread Anthony Minessale 
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 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
>
>
>
>
> >Please re-try with latest svn trunk.
> >
> >Mike
> >
> >On Nov 2, 2009, at 9:36 AM, Humberto Quintana wrote:
> >
> >>
> >> Thanks for you answers guys,
> >>
> >> I test the parameters you suggested
> >> but still no audio due to the lack of reINVITE. By the way I'm using
> >> 1.0.4 but I also tried 1.0.5pre3.
> >>
> >> One particular condition is that there is no on-hold before the
> >> Blind Transfer.
> >>
> >> Regards,
> >>
> >> Humberto
> >>
> >>> 
> >>> 
>
> --
> Lots of fantastic offers on Windows 7, in one convenient place. Get a deal
> on Windows 7 now 
>
> ___
> 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
>
>


-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_miness...@hotmail.com 
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org 
iax:gu...@conference.freeswitch.org/888
googletalk:conf+...@conference.freeswitch.org
pstn:213-799-1400
___
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

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

2009-11-02 Thread Humberto Quintana 

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



>Please re-try with latest svn trunk.
>
>Mike
>
>On Nov 2, 2009, at 9:36 AM, Humberto Quintana wrote:
>
>>
>> Thanks for you answers guys,
>>
>> I test the parameters you suggested
>> but still no audio due to the lack of reINVITE.  By the way I'm using
>> 1.0.4 but I also tried 1.0.5pre3.
>>
>> One particular condition is that there is no on-hold before the  
>> Blind Transfer.
>>
>> Regards,
>>
>> Humberto
>>
>>>   
>>>   
  
_
Lots of fantastic Windows 7 offers, in one convenient place. Get the perfect 
deal for you now.
http://go.microsoft.com/?linkid=9691633___
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

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

2009-11-02 Thread Michael Jerris 
Please re-try with latest svn trunk.

Mike

On Nov 2, 2009, at 9:36 AM, Humberto Quintana wrote:

>
> Thanks for you answers guys,
>
> I test the parameters you suggested
> but still no audio due to the lack of reINVITE.  By the way I'm using
> 1.0.4 but I also tried 1.0.5pre3.
>
> One particular condition is that there is no on-hold before the  
> Blind Transfer.
>
> Regards,
>
> Humberto
>
>>   
>>   


___
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

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

2009-11-02 Thread Humberto Quintana 

Thanks for you answers guys,

I test the parameters you suggested
but still no audio due to the lack of reINVITE.  By the way I'm using
1.0.4 but I also tried 1.0.5pre3.

One particular condition is that there is no on-hold before the Blind Transfer.

Regards,

Humberto

>  
>  

>> My scenario is as follows:
>>
>> inbound-bypass-media is set in the profile because we dont want FS handling
>> the media.
>>
>> 1. A calls B
>> 2. FS sends to B the A's SDP
>> 3. B answers
>> 4. FS sends to A the B's SDP
>> 5. Media going directly between A and B
>> 6. B REFERs the call to C (blind transfer with no reINVITE for Hold)
>> 7. FS accepts(202) the REFER and sends the NOTIFY
>> 7a. B and FS send the BYE
>> 8. FS sends an INVITE  to C with A's SDP
>> 9. C answers
>> 10. FS doesn't send a reINVITE to A to let it know about C's SDP
>>
>>
>> Is that the expected FS behavior or is this a bug?   
>>   
_
Ready for a deal-of-a-lifetime? See fantastic offers on Windows 7, in one 
convenient place.
http://go.microsoft.com/?linkid=9691634
___
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

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

2009-10-30 Thread Anthony Minessale 
profile options





On Fri, Oct 30, 2009 at 5:07 PM, Humberto Quintana wrote:

>  Hi everybody,
>
> I'd like some help with this situation that is 'haunting' me :-)
>
> My scenario is as follows:
>
> inbound-bypass-media is set in the profile because we dont want FS handling
> the media.
>
> 1. A calls B
> 2. FS sends to B the A's SDP
> 3. B answers
> 4. FS sends to A the B's SDP
> 5. Media going directly between A and B
> 6. B REFERs the call to C (blind transfer with no reINVITE for Hold)
> 7. FS accepts(202) the REFER and sends the NOTIFY
> 7a. B and FS send the BYE
> 8. FS sends an INVITE  to C with A's SDP
> 9. C answers
> 10. FS doesn't send a reINVITE to A to let it know about C's SDP
>
>
> Is that the expected FS behavior or is this a bug?
>
>
> I'd appreciate any hints. Thanks,
>
>
> Humberto
>
>
>
> --
> Lots of fantastic offers on Windows 7, in one convenient place. Get a deal
> on Windows 7 now 
>
> ___
> 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
>
>


-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_miness...@hotmail.com 
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org 
iax:gu...@conference.freeswitch.org/888
googletalk:conf+...@conference.freeswitch.org
pstn:213-799-1400
___
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

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

2009-10-30 Thread Brian West 

First you forgot to mention what SVN rev you're on...

/b

On Oct 30, 2009, at 5:07 PM, Humberto Quintana wrote:


Hi everybody,

I'd like some help with this situation that is 'haunting' me :-)

My scenario is as follows:

inbound-bypass-media is set in the profile because we dont want FS  
handling the media.


1. A calls B
2. FS sends to B the A's SDP
3. B answers
4. FS sends to A the B's SDP
5. Media going directly between A and B
6. B REFERs the call to C (blind transfer with no reINVITE for Hold)
7. FS accepts(202) the REFER and sends the NOTIFY
7a. B and FS send the BYE
8. FS sends an INVITE  to C with A's SDP
9. C answers
10. FS doesn't send a reINVITE to A to let it know about C's SDP


Is that the expected FS behavior or is this a bug?


I'd appreciate any hints. Thanks,


Humberto



Lots of fantastic offers on Windows 7, in one convenient place. Get  
a deal on Windows 7 now  
___

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


___
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

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

2009-10-30 Thread Humberto Quintana 

Hi everybody,

I'd like some help with this situation that is 'haunting' me :-) 

My scenario is as follows:

inbound-bypass-media is set in the profile because we dont want FS handling the 
media.

1. A calls B
2. FS sends to B the A's SDP
3. B answers
4. FS sends to A the B's SDP
5. Media going directly between A and B
6. B REFERs the call to C (blind transfer with no reINVITE for Hold)
7. FS accepts(202) the REFER and sends the NOTIFY
7a. B and FS send the BYE
8. FS sends an INVITE  to C with A's SDP
9. C answers
10. FS doesn't send a reINVITE to A to let it know about C's SDP


Is that the expected FS behavior or is this a bug?


I'd appreciate any hints. Thanks,


Humberto


  
_
Lots of fantastic Windows 7 offers, in one convenient place. Get the perfect 
deal for you now.
http://go.microsoft.com/?linkid=9691633___
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