OK. I give. This isn't something I know much about - I'm pretty sure you
know more about it than I do. So your issue isn't the processing of the
retransmission, its that processing the retransmission raises this
ambiguity about how to send responses.
I think Robert, Ben, or Adam are your best sources of an answer here.
Good luck,
Paul
Iñaki Baz Castillo wrote:
> El Lunes, 14 de Julio de 2008, Paul Kyzivat escribió:
>> If the request was truly *retransmitted*, it was because no response was
>> received to the original. If you have *received* the retransmission,
>> then why would you *not* want to process it? Ignoring it certainly isn't
>> going to make things better.
>
> Ok, but I repeat the sme question, what to do in the following case?
>
> - UAS receives a INVITE from IP_A.
> - UAS replies a 180 to IP_A. <-- last response sent
> - UAS receives a retransmission from IP_B.
> - UAS replies the above same 180 to IP_B.
> - Now UAS wants to reply a 200 OK, where should it send the reply? to IP_A or
> IP_B? And please, point me where this is defined and explained in RFC
> 3261/3263.
>
> A solution could be to send replies to IP from the last retransmission, this
> is, change the socket when a retransmission is received via a different
> socket than the original request or other retransmissions.
>
> But I say again: this is not defined in RFC 3261/3263, is it?
>
> Thanks a lot.
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
