[Freeswitch-users] transfer_ringback triggered by "183 Session progress"

[Irina Ivanova]

On 04/22/2011 12:34 PM, Irina Ivanova wrote:
> Thank you for the answer. I tried with both ignore_early_media=true 
> and ignore_early_media=false, but unfortunately in both cases the 
> behaviour is the same, the ringback_transfer is triggered.
> More than this, I've noticed that also with normal outgoing calls when 
> the channel is not answered before executing the bridge there is the 
> similar behaviour. As soon as 183 is received, the ringtone generated 
> by freeswitch can be heard (I suppose it is generated by freeswitch 
> because looking on the tcpdump of the call no any RTP stream sent to 
> freeswitch could be seen).
>
> In my first test ignore_early_media is set to false.
> As can be seen from the log here http://pastebin.freeswitch.org/16155 
> the line 168 says "entering state [early][180]" and at this moment the 
> caller starts to hear ringing.
>
> 165. 2011-04-22 11:30:45.931314 [DEBUG] sofia.c:4659 Channel 
> sofia/device/3382XXXXXX entering state [proceeding][183]
> 166. 2011-04-22 11:30:45.931314 [NOTICE] sofia.c:4737 Ring-Ready 
> sofia/device/3382XXXXXX!
> 167. 2011-04-22 11:30:45.933870 [NOTICE] mod_sofia.c:2185 Ring-Ready 
> sofia/internal/15 at 192.168.1.124!
> 168. 2011-04-22 11:30:45.933870 [DEBUG] sofia.c:4659 Channel 
> sofia/internal/15 at 192.168.1.124 entering state [early][180]
>
> The second test is made with ignore_early_media set to true.
> Here is the log of the test: http://pastebin.freeswitch.org/16156. On 
> the line 167 I can still see "entering state [early][180]" and I can 
> still hear the ringing.
> 167. 2011-04-22 12:05:21.450866 [DEBUG] sofia.c:4659 Channel 
> sofia/internal/15 at 192.168.1.124 entering state [early][180]
>
> I suppose it is meant to be like this, I am just wondering if there is 
> a way to avoid this short ringing sound that could disturb the 
> callers. May be some workaround?...
> I also played with uuid_broadcast and uuid_displace trying to 
> substitute the audio stream which is played to the caller as soon as 
> channel enters the state early, but at the end didn't get the desired 
> result.
>
>
>
> On 04/21/2011 04:17 PM, Brian West wrote:
>> Happen to be setting ignore_early_media=true?
>>
>>
>> On Apr 19, 2011, at 10:25 AM, Irina Ivanova wrote:
>>
>>> Hi,
>>>
>>> I've noticed that if to set transfer_ringback (to any ringback tone) 
>>> for
>>> already answered call and then to execute the bridge to some external
>>> number through the gateway, the ringing is triggered not only by "180
>>> Ringing" SIP response, but also when "183 Session progress" is 
>>> received.
>>> Does anybody know if there is a way to make transfer_ringback not to be
>>> triggered by 183? I need it because in the case when the destination
>>> number is busy and provider sends me 183 and then 486 (Busy here) the
>>> caller hears one ringback tone and then the busy tone which makes an
>>> impression that the called party rejected the call.
>>>
>>> Thanks,
>>> Irina
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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
>
>

Ok, I found the solution in the present mailing list, as the similar 
case was already discussed: 
http://lists.freeswitch.org/pipermail/freeswitch-users/2011-February/068693.html.
Shame on me I haven't noticed it before!

The trick is to use "sip_ignore_183nosdp" variable and to set it to 
"true" inside the dial string, so it's set on the b leg of the call.

And if I am not mistaken, the crash issue that was mentioned in the 
thread, is already fixed (git revision 
http://fisheye.freeswitch.org/changelog/freeswitch.git/?cs=ce5c846). 
Good job!