Odp: Re: can mod_httapi decide if the call should be answerred?
Thanks guys R On Thu, Jun 27, 2013 at 9:25 PM, Mariusz Czulada <manieq@wp.eu> wrote:
Rafał,
Dnia Czwartek, 27 Czerwca 2013 12:52 Rafal Gwizdala < rafal.gwizdala@gmail.com> napisał(a)
On Thu, Jun 27, 2013 at 12:49 PM, Rafal Gwizdala <rafal.gwizdala@gmail.com
wrote:
2. You don't need to answer the call in the httapi script This one looks quite strange but I think I finally understood it - I can play back sounds or 'say' something without explicitly 'answerring' the call. But the call is 'pre-answerred' only and in this state you won't be able to collect dtmf, for example. I don't know what is the exact difference between a pre-answerred and answerred call but one nice thing is that when you <hangup /> or <break /> in this state the call will be rejected and the caller will hear a 'busy' signal.
Session is established when you send 200/OK response (that's what "answer" does). This means media will be send in both directions.
What you experienced here is an early media mode. Because you did not explicitly called any responding app (neiher "answer" not "pre_answer") so mod_sofia did the second for you. "pre_answer" sends 183/Sesion Progress response. This means that B-side (your server) is willing to send media to other side. You should receive PRACK as a "response to response" if A-side accepts it. From this point you can send anything, but _should_ not expect any media to received. This is a situation similar to commonly used custom ring tones (with music).
Of course it is possible to use media in both/either side by setting P-Early-Media header in 183 response. Refer to RFC5009 for details.
Also keep in mind, that 183 _does_ _not_ establish a session. It means that calling side may expexty this is a free time like during ringing. If A-side is a UE of a local user (in terms of service, not distance/net) it will be probably ok. But if you connect FSW to some class 4/5 softswitch, it may be misleading, because the call can be not charged on calling side (i.e. provider). Only after sending 200/OK again ("answer" later) you will establish a call.
For all above I suggest you to explicitly call "answer" or "pre_answer" _before_ sending any media to other side. You will have 100% control of a call status and also not relay on mod_sofia responses which [are fine of course, but] may be different from what you intended (but now executed).
Hope it is clear enough ;)
Regards,
Mariusz
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
Those seem logical to be available without special permissions so I added them to latest GIT. answer preAnswer and ringReady tags. On Thu, Jun 27, 2013 at 4:06 PM, Rafal Gwizdala <rafal.gwizdala@gmail.com>wrote:
Thanks guys R
On Thu, Jun 27, 2013 at 9:25 PM, Mariusz Czulada <manieq@wp.eu> wrote:
Rafał,
Dnia Czwartek, 27 Czerwca 2013 12:52 Rafal Gwizdala < rafal.gwizdala@gmail.com> napisał(a)
On Thu, Jun 27, 2013 at 12:49 PM, Rafal Gwizdala < rafal.gwizdala@gmail.com> wrote:
2. You don't need to answer the call in the httapi script This one looks quite strange but I think I finally understood it - I can play back sounds or 'say' something without explicitly 'answerring' the call. But the call is 'pre-answerred' only and in this state you won't be able to collect dtmf, for example. I don't know what is the exact difference between a pre-answerred and answerred call but one nice thing is that when you <hangup /> or <break /> in this state the call will be rejected and the caller will hear a 'busy' signal.
Session is established when you send 200/OK response (that's what "answer" does). This means media will be send in both directions.
What you experienced here is an early media mode. Because you did not explicitly called any responding app (neiher "answer" not "pre_answer") so mod_sofia did the second for you. "pre_answer" sends 183/Sesion Progress response. This means that B-side (your server) is willing to send media to other side. You should receive PRACK as a "response to response" if A-side accepts it. From this point you can send anything, but _should_ not expect any media to received. This is a situation similar to commonly used custom ring tones (with music).
Of course it is possible to use media in both/either side by setting P-Early-Media header in 183 response. Refer to RFC5009 for details.
Also keep in mind, that 183 _does_ _not_ establish a session. It means that calling side may expexty this is a free time like during ringing. If A-side is a UE of a local user (in terms of service, not distance/net) it will be probably ok. But if you connect FSW to some class 4/5 softswitch, it may be misleading, because the call can be not charged on calling side (i.e. provider). Only after sending 200/OK again ("answer" later) you will establish a call.
For all above I suggest you to explicitly call "answer" or "pre_answer" _before_ sending any media to other side. You will have 100% control of a call status and also not relay on mod_sofia responses which [are fine of course, but] may be different from what you intended (but now executed).
Hope it is clear enough ;)
Regards,
Mariusz
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
participants (3)
-
Anthony Minessale
-
Mariusz Czulada
-
Rafal Gwizdala