transfer_ringback triggered by "183 Session progress"
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 -- ================================================================ Distinti saluti -- Irina Ivanova Settore Sviluppo MasterVoice tel: +39 0522 1590100 fax: +39 0522 331673 mob: +39 334 6449290 e-mail: i.ivanova@mastervoice.it web: www.mastertraining.it - www.registroelettronico.com Master Training S.r.l. Sede Legale: via Timolini, 18 - Correggio (RE) - Italy Sede Operativa: via Sani, 15 - Reggio Emilia - Italy Sede Commerciale: via Sani, 9 - Reggio Emilia - Italy ================================================================ Le informazioni contenute in questa e-mail sono da considerarsi confidenziali e esclusivamente per uso personale dei destinatari sopra indicati. Questo messaggio può includere dati personali o sensibili. Qualora questo messaggio fosse da Voi ricevuto per errore vogliate cortesemente darcene notizia a mezzo e-mail e distruggere il messaggio ricevuto erroneamente. Quanto precede ai fini del rispetto del Decreto Legislativo 196/2003 sulla tutela dei dati personali e sensibili. This e-mail and any file transmitted with it is intended only for the person or entity to which is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure.Copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this e-mail by mistake, please notify us immediately by telephone or fax.
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
-- ================================================================
Distinti saluti --
Irina Ivanova Settore Sviluppo MasterVoice
tel: +39 0522 1590100 fax: +39 0522 331673 mob: +39 334 6449290 e-mail: i.ivanova@mastervoice.it web: www.mastertraining.it - www.registroelettronico.com
Master Training S.r.l. Sede Legale: via Timolini, 18 - Correggio (RE) - Italy Sede Operativa: via Sani, 15 - Reggio Emilia - Italy Sede Commerciale: via Sani, 9 - Reggio Emilia - Italy
================================================================ Le informazioni contenute in questa e-mail sono da considerarsi confidenziali e esclusivamente per uso personale dei destinatari sopra indicati. Questo messaggio può includere dati personali o sensibili. Qualora questo messaggio fosse da Voi ricevuto per errore vogliate cortesemente darcene notizia a mezzo e-mail e distruggere il messaggio ricevuto erroneamente. Quanto precede ai fini del rispetto del Decreto Legislativo 196/2003 sulla tutela dei dati personali e sensibili. This e-mail and any file transmitted with it is intended only for the person or entity to which is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure.Copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this e-mail by mistake, please notify us immediately by telephone or fax.
_______________________________________________ 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
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@192.168.1.124! 168. 2011-04-22 11:30:45.933870 [DEBUG] sofia.c:4659 Channel sofia/internal/15@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@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
-- ================================================================
Distinti saluti --
Irina Ivanova Settore Sviluppo MasterVoice
tel: +39 0522 1590100 fax: +39 0522 331673 mob: +39 334 6449290 e-mail: i.ivanova@mastervoice.it web: www.mastertraining.it - www.registroelettronico.com
Master Training S.r.l. Sede Legale: via Timolini, 18 - Correggio (RE) - Italy Sede Operativa: via Sani, 15 - Reggio Emilia - Italy Sede Commerciale: via Sani, 9 - Reggio Emilia - Italy
================================================================ Le informazioni contenute in questa e-mail sono da considerarsi confidenziali e esclusivamente per uso personale dei destinatari sopra indicati. Questo messaggio può includere dati personali o sensibili. Qualora questo messaggio fosse da Voi ricevuto per errore vogliate cortesemente darcene notizia a mezzo e-mail e distruggere il messaggio ricevuto erroneamente. Quanto precede ai fini del rispetto del Decreto Legislativo 196/2003 sulla tutela dei dati personali e sensibili. This e-mail and any file transmitted with it is intended only for the person or entity to which is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure.Copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this e-mail by mistake, please notify us immediately by telephone or fax.
_______________________________________________ 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
-- ================================================================ Distinti saluti -- Irina Ivanova Settore Sviluppo MasterVoice tel: +39 0522 1590100 fax: +39 0522 331673 mob: +39 334 6449290 e-mail: i.ivanova@mastervoice.it web: www.mastertraining.it - www.registroelettronico.com Master Training S.r.l. Sede Legale: via Timolini, 18 - Correggio (RE) - Italy Sede Operativa: via Sani, 15 - Reggio Emilia - Italy Sede Commerciale: via Sani, 9 - Reggio Emilia - Italy ================================================================ Le informazioni contenute in questa e-mail sono da considerarsi confidenziali e esclusivamente per uso personale dei destinatari sopra indicati. Questo messaggio può includere dati personali o sensibili. Qualora questo messaggio fosse da Voi ricevuto per errore vogliate cortesemente darcene notizia a mezzo e-mail e distruggere il messaggio ricevuto erroneamente. Quanto precede ai fini del rispetto del Decreto Legislativo 196/2003 sulla tutela dei dati personali e sensibili. This e-mail and any file transmitted with it is intended only for the person or entity to which is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure.Copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this e-mail by mistake, please notify us immediately by telephone or fax.
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@192.168.1.124! 168. 2011-04-22 11:30:45.933870 [DEBUG] sofia.c:4659 Channel sofia/internal/15@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
_______________________________________________ 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
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..... 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!
participants (2)
-
Brian West
-
Irina Ivanova