[Serusers] Tags, forwarding, redirects, and picky UACs

[Bogdan-Andrei Iancu]

first, it's not about FROM tag, but TO tag...
second, it's better to do it for all provisional responses < 180 (for 
183 you might mess with early media)
third, here  it 's the  regexp:

 onreply_route[1]{
    if ( t_check_status("(1[0-7][0-9])|(180)") ) {
        subst('/^(To:.*)\;tag=[^;[:cntrl:]]*/\1/i');
    }
    break;
}

bogdan


Alistair Cunningham wrote:

> Bogdan-Andrei,
>
> Can you please give me a hint as to how to remove the tag? I've can do 
> something like:
>
> onreply_route[1] {
>     if ( (status=~"180") ) {
>     replace( ";tag=.*", "" );
>     };
> }
>
> but this would remove the tag from all headers. I could add "From:" 
> into the regular expression, but this would then remove the whole From 
> header.
>
> Alistair Cunningham,
> Integrics Ltd,
> +44 (0)7870 699 479
> http://integrics.com/
>
>
> Bogdan-Andrei Iancu wrote:
>
>> According to RFC 3261, the UAC *must* drop any To-tag received in a 
>> provisional reply in favour of the To-tag advertised in the final 
>> reply - be this it means not only to accept a final reply with a 
>> different To-tag, but also to use it in generating sequential 
>> messages (like ACK, re-INVITEs, etc)
>>
>> So you should report the problem to your UAC vendor. Meanwhile you 
>> can do a trick in SER cfg - use a reply_route to remove the To-tag 
>> from all provisional replies....this will make happy the UAC.
>>
>> bogdan
>>
>> Alistair Cunningham wrote:
>>
>>> I'm trying to implement forwarding to voicemail with a UAC that's picky
>>> about the tags in the To: headers it receives.
>>>
>>> First, I tried the following:
>>>
>>> failure_route [1] {
>>>     rewritehostport("192.168.1.1:5060");
>>>     append_branch();
>>>     t_relay();
>>> }
>>>
>>> This failed because the UAC received a "180 Ringing" from the ringing
>>> Grandstream phone via ser that contained a To: tag. After the timeout,
>>> it received another 180 from Asterisk (the voicemail system) with a
>>> different tag. Since it doesn't support forked INVITES, it dropped 
>>> the call.
>>>
>>> Then I tried:
>>>
>>> failure_route [1] {
>>>     rewritehostport("192.168.1.1:5060");
>>>     t_reply( "302", "Moved Temporarily" );
>>> }
>>>
>>> This time it receives the 180 from the phone as before. Then it 
>>> receives
>>> the 302. Alas, SER has ignored the tag from the phone, and created a 
>>> new
>>> one of it's own, so the UAC again drops the call.
>>>
>>> Does anyone know of a way round this? Can SER be persuaded to use a tag
>>> it has already received? Can I strip the tag from the To: header in 
>>> one or both of the responses? I'm willing to get my hands dirty with 
>>> the SER source code if necessary.
>>>
>>
>>
>>