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.
Bogden,
You're quite correct, it's To:. I'm not thinking clearly today. It works - thank you very much!
Alistair Cunningham, Integrics Ltd, +44 (0)7870 699 479 http://integrics.com/
Bogdan-Andrei Iancu wrote:
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.