Hi all,
I find an issue with a problem encountered on some products.
The problem only concerns on-net calls. In fact, when a SER User A calls a SER User B :
- if B doesn't answer, after the tm timer :
==> t_on_failure("1") ==> setflagt(24) ==> load $ruri/username in vm_uri/usr_vm if flag is set to 24 then ==> avp_pushto $ruri s:vm_uri ==> resetflag(24) ==> add prefix Prefix("710") ==> rewritehostport(Asterisk:4060) ==> append_branch ==> t_relay_to_udp(Asterisk,4060)
This is the process apply for transfer the call to the voicemail Asterisk.
But, and only in this on-net case, the To-Tag change during this process, cause the failure of communication for some products.
Whereas the RFC 3261 specify "... This tag will be incorporated by both endpoints into the dialog and will be included in all future requests and responses in this call ...".
Thanks for your support.
No one have an idea ?
Le lundi 03 décembre 2007 à 17:37 +0100, inge a écrit :
Hi all,
I find an issue with a problem encountered on some products.
The problem only concerns on-net calls. In fact, when a SER User A calls a SER User B :
if B doesn't answer, after the tm timer :
==> t_on_failure("1") ==> setflagt(24) ==> load $ruri/username in vm_uri/usr_vm if flag is set to 24 then ==> avp_pushto $ruri s:vm_uri ==> resetflag(24) ==> add prefix Prefix("710") ==> rewritehostport(Asterisk:4060) ==> append_branch ==> t_relay_to_udp(Asterisk,4060)
This is the process apply for transfer the call to the voicemail Asterisk.
But, and only in this on-net case, the To-Tag change during this process, cause the failure of communication for some products.
Whereas the RFC 3261 specify "... This tag will be incorporated by both endpoints into the dialog and will be included in all future requests and responses in this call ...".
Thanks for your support.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
inge wrote:
No one have an idea ?
This has been discussed some weeks ago, IIRC. A solution that has been suggested was to create an onreply-route to store the first To-tag seen in a response (18x). Then, before relaying to the Asterisk in the new branch, set the To-tag of the outgoing INVITE to the one seen previously. This is kinda dirty, but has been reported to work in this special case (with Asterisk).
HTH, Olaf
Thanks a lot for your answer !
Is it possible to find the logs of the discussion somewhere ?
Moreover, is there an example of quick fix implementation ?
Regards,
Adrien
Le mardi 11 décembre 2007 à 10:00 +0100, Olaf Bergmann a écrit :
inge wrote:
No one have an idea ?
This has been discussed some weeks ago, IIRC. A solution that has been suggested was to create an onreply-route to store the first To-tag seen in a response (18x). Then, before relaying to the Asterisk in the new branch, set the To-tag of the outgoing INVITE to the one seen previously. This is kinda dirty, but has been reported to work in this special case (with Asterisk).
HTH, Olaf
inge wrote:
Is it possible to find the logs of the discussion somewhere ?
http://lists.iptel.org/pipermail/serusers/2007-October/034224.html
Regards, Olaf
Thanks.
I think I well understand the problem.
Seems that the problem comes from my hardware UA and not Asterisk.
How can I implement a solution to palliate the poor realization of UAS hardware ?
Just for the case of CallForward on busy and non answer.
I am a bit lost on this more functional aspect
Le mardi 11 décembre 2007 à 13:29 +0100, Olaf Bergmann a écrit :
inge wrote:
Is it possible to find the logs of the discussion somewhere ?
http://lists.iptel.org/pipermail/serusers/2007-October/034224.html
Regards, Olaf
Olaf Bergmann schrieb:
inge wrote:
No one have an idea ?
This has been discussed some weeks ago, IIRC. A solution that has been suggested was to create an onreply-route to store the first To-tag seen in a response (18x). Then, before relaying to the Asterisk in the new branch, set the To-tag of the outgoing INVITE to the one seen previously. This is kinda dirty, but has been reported to work in this special case (with Asterisk).
I also had this problem with Asterisk as caller in pedantic mode and fixed it be removing the to-tag from 180/183 responses (very dirty but it works as now Asterisk can not learn the to-tag from provisional responses)
regards klaus