El Miércoles, 9 de Julio de 2008, Rockson Li (zhengyli) escribió:
> > The problem is that the UAS transaction layer must reply with the last
> > response for the original request, but this reply is not exactly the same
> > since top Via can be different ("received" and "rport") so the reply would
> > be modified before re-send. Also the socket to use is different. 

> I think for UDP, the response for retransmission of req would sent to the
> addr:port the original req comes from, Since the received and rport is
> populated as addr:port the original req comes from , when server
> transaction notice that it need reply to a retransmitted req, It just give
> transport layer the previous sent response, which have received and rport
> already.
>
> So when transport get the response, it just does as per RFC3581, send the
> reponse as per received and rport, which is the addr:port the original req
> comes from.
>
> It should be OK, since both UAC and NAT will live the origianl addr:port
> open.

Imagine this case:
- UAC sends an INVITE by UDP to UAS via IP1.
- The INVITE arrives to UAS who sends the reply via IP1.
- But a network error occurs and that route is closed.
- UAS tries also fails to send response performing NS resolutions of "sent-by" 
parameter.
- UAC resends the same INVITE but because network has changed the INVITE 
arrives to UAS from IP2. It's a retransmission.
- If UAS resends the response to IP1 (as you suggest) it will fail forever.

Doesn't make sense in this case that the response should be sent to IP2 (from 
where the retransmitted INVITE arrives)?


Regards.


-- 
Iñaki Baz Castillo

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to