The way I interpret this excerpt, I would rather say "Fortunately yes" because it means it has to be fixed in PJSIP and not be hacked around on the application side. >From RFC 3261 [5], just to make sure that I have the right understanding of "transaction" : "A transaction is a request sent by a client transaction (using the transport layer) to a server transaction, along with all responses to that request sent from the server transaction back to the client. The transaction layer handles application-layer retransmissions, matching of responses to requests, and application-layer timeouts." With "The transaction layer handles application-layer retransmissions, matching of responses to requests", then the REGISTER sent after a 407 challenge is part of the transaction and therefore, the DNS procedures defined in RFC 3263 [4] must be applied. On Fri, 2009-07-17 at 16:29 +0200, Klaus Darilion wrote: > > Pierre-Luc Bacon schrieb: > > > > Now, does the RFC say to do so ? > > Unfortunately yes. > > RFC 3263: > > > The procedures here MUST be done exactly once per transaction, where > > transaction is as defined in [1]. That is, once a SIP server has > > successfully been contacted (success is defined below), all > > retransmissions of the SIP request and the ACK for non-2xx SIP > > responses to INVITE MUST be sent to the same host. Furthermore, a > > CANCEL for a particular SIP request MUST be sent to the same SIP > > server that the SIP request was delivered to. > > From a practical point of view this is bad (as you experienced), > because if there is a dialog stateful element (e.g. SBC, IP-PBX), the > in-dialog requests will be rejected and nonces wont be accepted. > > Thus, IMO the client should send all messages which belong together > (re-registrations, in-dialog requests) to the same IP address (usually > the one which was resolved during initial registration). Only if there > is a problem, the domain should be resolved again and a new IP should be > choosen. > > regards > klaus >
