[asterisk-dev] Organising the cases when a channel is hanged up

[Zoltan Gaspar]

Hi,



Let's see what I'm talking about:



Phone                       Asterisk                          Outbound
provider

             -------à                                ------à

        Inbound channel                    outbound channel



In general let's call the inbound channel the channel between the
originator(source) and asterisk and outbound channel the channel between
asterisk and the destination.



My discussion will about when and why should a channel (inbound or outbound)
be hanged up (terminated, killed, suspended, canceled call this process as
you like).



I want to present you the current state of this matter in asterisk 1.2 (and
I belive so in 1.4).



When using the Dial application according to the options you are useing and
the hangup reason you may get one of the results:

1) Outbound channel is canceled and inbound channel is active

2) Outbound channel is canceled and inbound channel is canceled too.



The problem is when you wish to end in a certain case all the time and you
can't control it.



 If you arrive sometimes, or all the time in case 1 you can simply put a
hangup after that dial and problem is fixed. If you arrive in case 2 and
still want to use it there is not to mutch to do, after the channel is
hanged up you can't really play a message on it (belive me I've tried
it J), and start .



The next question you might ask yourself is when and how did I got in that
situation so here it goes:

Answer

Saynumber(1234)

Dial(SIP/number at provider||S(20)g)

Saynumber(4321)

Hangup



S option terminates the call x seconds after the called party picked up.

g When the called party hangs up, exit to execute more commands in the
current context.



If the call is haned up by the called party the caller can hear the 4321, if
the call times out (the called party didn't hang up in x seconds) the caller
cannot hear the Saynumber(4321) giving a warning or notice depending on how
is this application succession implemented.



A previous discussion on this manner can be found at
http://bugs.digium.com/view.php?id=9888 starting from post 0064808 . If I'm
not too clear in this email you may find additional details posted there.



I used DeadAGI and AGI to run this sequence it is not this that is
important, the bigger picture is.



So we got a case (others may have found other cases) where after a dial the
inbound channel is no longer up, and there is no option to avoid this. In
order to make asterisk better and suitable for a wider range of problems,
and easyer to work with, we need to organise the cases when an inbound
channel is hanged up, so that all the combinations of applications will
work.



I think if the following set of rules would be implemented, the problem
mentioned above and many others would be solved.



Rule 1) The inbound channel can be hanged up only by the Hangup application
or the hanging up event of the inbound party

Rule 2) The outbound channel can be hanged up by:
-> Inbound party hanging up
-> Outbound party hanging up
-> A timeout option being set up -> Options L and S from app Dial

Rule 3) All aplications that work with channels can be categorized into:
a) Applications working on the inbound channel: Playback, saynumber,
getdigit Do not hang up any channel.
b) Applications for creating/mixing/tieing channels: Dial/conference/Queue
Hang up only the outbound channel that they might created.

Rule 4) The functionality is not conditioned by the way the applications are
being called: Dialplan(Realtime or not) or Agi (Deadagi)

Rule 5) Sip reinvites being sent out or not will not effect the hangup of
inbound or outbound channels, they will be transparent

Effect 1) An explicit hangup is required for each inbound call
Effect 2) After a dial the inbound channel can always be used (not being
conditioned by the outbound channel hangup reason -> kind of logical
asumption I think)
Effect 3) Sip reinvites can be sent out in a greater number of cases,
optimizeing the codec used and the RTP path of a call. Lower delay and less
transcoding, better call quality and lower load on the server, better
performace are just some of the reasons why.



About the implementation I think that adding a parameter to the dial
application that will force this behavior would solve it and be backwards
compatible too.



Please give me your opinion on this, pointing out where I might be wrong.



Thanks

Gaspar Zoltan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20070613/3f0685f5/attachment-0001.htm