Hi Alex,
As I said I was doubting about this inference, but as calls are working with other providers and I read the post I linked, I don't really know in what side the solution is.
The scenario is as follows:
Softphone A - providerProxy - myProxy - Softphone B
Softphone A sends the invite to Softphone B through providerProxy and myProxy Softphone B sends the 200OK with CONTACT: "user@softphone_B_contact_URI" to myProxy myProxy sends the 200OK with CONTACT: "user@softphone_B_contact_URI" to providerProxy providerProxy sends the 200OK with CONTACT: "user@myproxy_IP_address" to Softphone A Softphone A sends ACK "sip:user@myproxy_IP_address" and when it arrives to myproxy it is never sent to Softphone B and there is a timeout 30 seconds later.
Is there anything I can do to solve this?
Thank you, Ricardo
-----Mensaje original----- De: sr-users-bounces@lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org] En nombre de Alex Balashov Enviado el: martes, 15 de marzo de 2011 17:25 Para: sr-users@lists.sip-router.org Asunto: Re: [SR-Users] ACK not sent and rr-enforced
On 03/15/2011 08:28 AM, Dominguez Jover, Ricardo wrote:
Should I infer IPTEL.org is not implementing SIP RFC 3261 in the right way? It seems odd to me...
No, Ricardo, that is not the correct inference. First, if the ACK is an
end-to-end ACK (as for a 200 OK), it is generated by the sending endpoint, and the SER proxy is not responsible for constructing it. Secondly, there are various reasons why an ACK may have a request line not equal to the Contact URI established as the dialog target, having to
do with backward compatibility with RFC 2543.