Andy, see inline
Jeroen, Thanks a lot for your emails. Let us say the call distributor hands off these INVITEs to UAs (and not proxies), then the UA can directly send the response to the UAC, say 180 or 200 with its own Contact header. In such a case, the PRACK (for 180) or ACK for 200 Ok, would directly reach the UA. So you mean that the distributor would not add its own Via header? If it did, the response would always go back via the distributor; the receiving UA has no choice in that I think RFC3261 only considers SIP elements that do add a Via header, perhaps such a 'relay' kind of device would be interesting to consider too A re-transmitted INVITEs would also get routed to same UA (until the distributor maintains the state). Would such an approach work for TCP as well? Or in cases of TCP the ACK would still have to go thorugh the distributor and later the UAS should send an UPDATE to change the port? For TCP you could use the same mechanism that HTTP redirectors use (i.e. packet rewriting), without inspecting the SIP messages at all. It would then stay in the traffic path though. If you want to stay at the SIP level, I suppose the Contact mechanism would work in the same way; the SIP ACK (not the TCP ACK) would get sent directly to the callee UA (cost : 2 TCP connection setups). Retransmission behavior for TCP would be different, as soon as the distributor would see a response with a contact (1xx or 2xx, not error responses as those would get ACKed) it could close the connection and remove the state. As an optimization, you could consider to associate the per-client state (i.e. the target UA the INVITE was forwarded to) with the TCP connection, so not per call-id. If the client sends more than 1 INVITE over the connection they would then all be sent to the same UA though. Perhaps an alternative distribution mechanism could be to send "302 Moved Temporarily" in response to each INVITE. You would get the ACKs, but there's no need to maintain state anymore since the calling UAC will filter duplicate responses to retransmitted INVITEs. SIP "decoding" would remain limited to the headers you need for the response (To, From, Call-Id, first Via, CSeq). This does add delay to each call setup (1 RTT) Jeroen _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
