Hi, Can we elaborate on the (re)REGISTER case ?
> They should repeat the resolution and selection when they > refresh the registration returned by sip2 (which is what most > clients we've worked with do). Isn't this in contrast to what is stated in the standards (see below) ? I assume these statements are there in order to avoid that a user is registered via different registration paths. RFC 3261 10.2.4 " Registration refreshes SHOULD be sent to the same network address as the original registration, unless redirected." 3GPP TS24.228 Registration signalling: reregistration - user currently registered "The registration expires in the UE. The UE reregisters by sending a new REGISTER request. This request is sent to the same P-CSCF with which the UE initially registered.Upon receiving this request the P-CSCF will detect that it already has a registration record for this UE and will reset it's SIP registration timer for this UE to the Expires time in this request." Thanks, Ben. > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On > Behalf Of Scott Lawrence > Sent: woensdag 11 maart 2009 15:11 > To: Iñaki Baz Castillo > Cc: sip-implementors > Subject: Re: [Sip-implementors] About SRV when the host with > highest priority becomes reachable > > On Wed, 2009-03-11 at 14:46 +0100, Iñaki Baz Castillo wrote: > > Hi, imagine a domain "myomain.org" with a SRV _sip._udp register > > pointing to two hosts: > > > > sip1.mydomain.org (priority 1) > > sip2.mydomain.org (priority 2) > > > > Clients MUST contact sip1.mydomain.org since this entry has higher > > priority. In case sip1.mydomain.org is down, clients MUST > inmediately > > use sip2.mydomain.org. > > But when should they try to use sip1.mydomain.org? > > > > Basically I want that clients to come back to the first > host and leave > > using the second host when sip1.mydomain.org becomes > reachable again. > > > > What should be the client behaviour? > > What is the real behaviour of current clients supporting DNS SRV? > > They should repeat the resolution and selection when they > refresh the registration returned by sip2 (which is what most > clients we've worked with do). > > If you wanted to force clients to move back as quickly as > possible, you could arrange to have sip2 return shorter > registrations than sip1 does. > There's danger in this, though, since it means sip2 will have > higher load than sip1 did (in a large system with short > registration times, registration load can be significantly > higher than calls). > > In our system, we make the priorities equal and synchronize > the registrations between registrars, so they provide both > redundancy and load sharing. It doesn't matter which > registrar a client uses. > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
