Bogdan-Andrei,
Can you please point me to where in the RFC says this? I suspected this
myself, did some reading, and came up with the following from section
8.2.6.2:
"The same tag MUST be used for all responses to that request, both final
and provisional (again excepting the 100 (Trying))."
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.