Juha Heinanen wrote on 10/27/2014 12:45 PM:
> Juha Heinanen writes:
>
>> one more piece of information: it is 480 reply to connectCallee that
>> results in clearing of the call. 486 reply works fine. perhaps this
>> gives a clue to figuring out where the problem is.
>
> ok, i found the reason, why 480 reply to connectCallee clears the whole
> b2b call.
>
> in AmBasicSipDialog::onRxReply(const AmSipReply& reply) there is this
> check:
>
> if(onRxReplyStatus(reply) && hdl) {
> hdl->onSipReply(orig_req,reply,saved_status);
> }
>
> and onRxReplyStatus(reply) has:
>
> switch(reply.code){
> ...
> case 480:
> ...
> if(hdl) hdl->onRemoteDisappeared(reply);
>
> if i remove 480 from the list, connectCallee does not clear the b2b call
> when 480 reply is received from callee. that allows the ivr application
> to try another callee with new connectCallee call.
>
> of course removing 480 from list of dialog terminating response codes is
> a hack. the bug is somewhere else, i.e., it should be possible to try
> other callee legs when one of them fails with whatever response code.
>
> any suggestions for the real fix?
I still have to have a look at the code, but in DSM what we do is that
the script, e.g. in a call control DSM, can prevent the whole event
(sipReply event) to be processed the normal/default way
(set(#ContinueProcessing=false) or so). That's also in general the
normal way how applications override and customize the default sems
way of handling things. Maybe it would help to add something in that
style to ivr as well, e.g. in a return value of the python function?
Stefan
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
