I think that we are facing a dilemma here. Digressing the RFC would make PJSIP to work properly in this case (which might appear with a lot more VOIP providers doing load balancing). However, leaving it untouched makes the matter way more complex to deal with in the application. A possible workaround and maybe the only one I see, would be to resolve the host name initially, and use that IP from the moment the user launched the application to the end. Not so pretty ... I'm not familiar with SIP load balancing but should a "good" load balancer infrastructure be able to forward 407 challenges among themselves ? That way, a server which didn't send that challenge initially can answer back properly to that new REGISTER. On Fri, 2009-07-17 at 17:29 +0200, Klaus Darilion wrote: > > Pierre-Luc Bacon schrieb: > > 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. > > No. > > Every REGISTER is a separate transaction - except retransmissions which > can be identified by being completely identical in contrast to the new > REGISTER request which is different (at least CSeq or call-id or > from-tag or Via-branch are different). > > Actually, the branch-parameter in the via header is used for transaction > matching. Thus, a new branch parameter indicates a new transaction. > > Thus, pjsip/pjsua-lib behaves standard conform, but is not useable in > practical. > > regards > klaus > > > > > 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 > >> > >
