20 Dec
2008
20 Dec
'08
7:09 a.m.
Daniel-Constantin Mierla a écrit :
On 12/19/08 10:10, Aurelien Grimaud wrote:
Well, this is a home made reply from a pstn gateway.
The pstn gateway sens request to a pstn network equipement.
As soon as the pstn equipements answers a Progress, a 101 is relayed to
openser.
It contains really early sdp.
I thought it smart.
I am not so sure now !
Aurelien
Klaus Darilion a écrit :
101 - I haven't heard of such reply so far ... what is the reason phrase?
Strange!
Nevertheless there is no need to drop 100 as 100 is never relayed.
Yep, my mistake !
The first destination chosen for serial forking was sending a 101
with sdp, which was relayed to caller.
But this first destinaion failed to establish the
call, so the
request was serial forked to another destination, sending another 101
sdp, then 180 sdp and 200 sdp which are relayed to caller.
The problem is that caller did not take into account the next sdp but
stay stucked to initial one (the one that failed).
When tm timer triggers, there is a CANCEL which is sent to initial
destination right ?
Yes.
Well, maybe 100 does not change timers from fr to
fr_inv, and I did
not notice before as 180 was coming very fast ?
I checked the source, but the test in t_reply before updating the
timer is not obvoious to see wether timer are canceled on 100 or 180 :-)
One thing is sure. If you drop the reply, timer will not be changed.
If you dropped it in default onreply route then tm does not get it.
Cheers,
Daniel
The destination was a mobile device on PSTN.
180 may be really delayed, and I am not even sure they are mandatory !
Aurelien
klaus
Aurelien Grimaud wrote:
> Daniel-Constantin Mierla a écrit :
>
>> Hello,
>>
>> On 12/18/08 13:18, Aurelien Grimaud wrote:
>>
>>> Hi,
>>> In my openser, I had to not relay any provisional which is < 180.
>>> I used drop in reply route to do this.
>>> No provisional < 180 is sent to caller.
>>>
>>> Unfortunately, dropping 100 seems to make the transaction module
>>> not disarming its fr_timer.
>>>
>> 100 is disabling the retransmission timer. fr_timer is the
>> duration to wait until a final response is received, not related
>> to retransmission and 100 reply.
>>
>>
> - fr_timer is armed when INVITE is t_relayed and disarmed *only*
> when a final response is received.
> - fr_inv_timer is armed whenever a provisional (100 - 199) is
> received, disarmed on final response .
> Well, fr_timer also has to be disarmed when fr_inv_timer is armed
> right ?
>
> So any provisional (100-199) disarm fr_timer and arm fr_inv_timer.
> But you have not to drop it in reply_route.
>
> In my case, the reply_route I set drops any provisional < 180.
> This means that the 100 response will not make tm module switch
> fr_timer to fr_inv_timer as it would be if not dropped.
>
> Well this is not a problem, I only dropped provisional from 101 to
> 180, and all went back to normal.
> Since 100 is not forwarded (because of t_relay already generated
> one), this makes no difference for end users.
>
> I did not expect drop() statement to change anything for timers.
>
> Thanks.
> Aurelien
>
>
>> Cheers,
>> Daniel
>>
>>
>>> The 180 has been waited for more time than my fr_timer so request
>>> failed and failure_route was called.
>>> In fact, there is no 180, only a 200 ok.
>>>
>>> Can anyone confirm that disarming timer is *not* done if 100 is
>>> dropped ?
>>>
>>> This is openser 1.2.1
>>>
>>> Regards.
>>> Aurelien
>>>
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel(a)lists.kamailio.org
>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
>>>
>>>
>
> _______________________________________________
> Devel mailing list
> Devel(a)lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
>
_______________________________________________
Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users