Jo, Thank you for reply. The concern here is the interoperability. If the RFC/Drafts can mandate this implementation, isn't it better? Chris Jo Hornsby wrote: > > In rfc2543bis-02.ps (p75) it says > > > > "If a server needs to return a response to a client and no longer > > has a connection open to that client, it MAY open a connection to > > the address listed in the Via header. Thus, a proxy or user agent > > MUST be prepared to receive both requests and responses on a > > "passive" connection"." > > > > And on P59 it says: > > > > "The client originating the request MUST insert into the request a > > Via field containing the transport protocol used to send the > > message, the client's host name or network address and, if not the > > default port number, the port number at which it wishes to receive > > responses. (Note that this port number can differ from the UDP > > source port number of the request)." > > > > Combining these two statements, can we get the conclusion that the > > Draft is requiring UAC to be repared to receive reponses not only on > > the TCP connection > > (If you mean the TCP connection over which the request was sent, > yes.) > > > (in UDP case it will be the connect socket) > > It's unlikely to be the connected UDP socket, unless you connected > the socket that is also listening on 5060 (or whatever your main > port is). > > > but > > also on the listening ports of UAS(C?) (in the UDP case, it will be > > a non-connect socket)? > > Very much so. > > > So even a response coming from a different IP > > address, the UAC SHOULD be able to receive it according to the > > Draft/RFC?? Does the Draft/RFC madate this implementation? > > The draft is silent on this issue, thus I guess you have to > be prepared for the source address to be different from what > you might expect. Although if a server actively opened up > a TCP (or other reliable transport) connection to me as a > client, when the original (i.e., request) connection was still > present, I would consider it a little odd. > > - Jo. > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
