[Users] purposely dropping reply message

Bogdan-Andrei Iancu bogdan at voice-system.ro
Wed May 16 11:15:13 CEST 2007


Klaus Darilion wrote:
>
>
> Bogdan-Andrei Iancu wrote:
>> Hi,
>>
>> actually you can "drop" negative final replies - it is not drop but 
>> rather replacement - it might be useful. Do in failure route:
>>
>>    if (t_check_status("400")) {
>>       t_reply("xxx","my new reply");
>>       exit;
>>    }
>
> this wont help Tim as any reply stops retransmissions.
yes, it wont - just drop (without sending anything) is not possible....
> btw: If the clients uses TCP there wont be retransmissions at all.
yes, retransmissions are only for UDP.

Regards,
bogdan
>
> regards
> klaus
>
>
>>
>> regards,
>> bogdan
>>
>> Klaus Darilion wrote:
>>>
>>>
>>> Tim wrote:
>>>> Hello,
>>>>
>>>> How/Where would be the best place to purposely drop a particular reply
>>>> message ( > 400 )
>>>>
>>>> I have armed both the reply route and failure route and attempted 
>>>> to drop
>>>> the message by calling the drop() function but this doesn't seem to 
>>>> work.
>>>> Is there a simple method for conditionally dropping a reply message?
>>>
>>> Dropping for final response messages is not supported.
>>>>
>>>> My goal is to force the UAC that created the original request to 
>>>> retransmit
>>>> (UDP) the request in certain scenarios, such as when ACK to an initial
>>>> invite has not been fully processed by the downstream UAS but a 
>>>> re-invite
>>>> has been received by the UAS causing the UAS to return a 400 for the
>>>> re-invite.  I do not want the UAC to see the 400 reply, instead I 
>>>> simply
>>>> want the UAC to resend the re-invite because no final response has 
>>>> been
>>>> received, presumably by this time  the ACK processing will be 
>>>> finished and
>>>> the retransmitted re-invite would be handled smoothly.
>>>
>>> Are you sure that the retransmitted reINVITE is accepted by the 
>>> client after the ACK was received? I would rather suggest to fix the 
>>> client. A reINVITE before the ACK is an implicit ACK and thus the 
>>> client should handle it as a ACK was received. I think this is also 
>>> stated somewhere in RFC 3261.
>>>
>>> regards
>>> klaus
>>>> I realize replies are routed based on via headers.  Is there some 
>>>> way to
>>>> short circuit this routing other than drop()?
>>>>
>>>> Thanks
>>>>
>>>> Tim
>>>>
>>>>
>>>> Tried this from failure route
>>>>
>>>> if(t_check_status("400"))
>>>>        {
>>>>                xlog( "L_ERR", "400 message in failure route 2 
>>>> **********
>>>> \n" );
>>>>                drop();
>>>>                return;
>>>>        }
>>>>
>>>> Tried this from reply route
>>>>
>>>> if(status == "400")
>>>>        {
>>>>                xlog( "L_ERR", "400 in reply route 2 .... 
>>>> dropping\n" );
>>>>                drop();
>>>>                return;
>>>>        }
>>>>
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at openser.org
>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>
>





More information about the Users mailing list