I agree with you Dale, If Call-id is same for both pseudo-dialog, and then incoming INVITE MUST be routed to UA which has recent registration.
Otherwise (if Call-id is different), incoming INVITE must be forked to both UAs Thnx for your interest, Erol On 2/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > From: "erol turac" <[EMAIL PROTECTED]> > > If an endpoint sends initial invites with ip address A, and then it > sends > sub register messages with a different ip address B, > How does the UAS handle this request ? Does UAS response with 200 OK or > 5xx > server error ? > > This is the correct way to think about this situation: > > When the registar receives REGISTER messages, all REGISTER messages > with the same Call-Id are (logically) grouped together. I call the > group a "pseudo-dialog", because it resembles a dialog in some ways > but not in others. > > The REGISTERs in one pseudo-dialog are (except for some special cases) > independent of the REGISTERs in other pseudo-dialogs. Only the last > REGISTER in a pseudo-dialog (the one with the highest CSeq) has any > effect, and of course, only until its expiration time. Usually all > REGISTERs in a pseudo-dialog all register the same one contact, > although they can register multiple contacts, and those contacts can > change over time. > > In your case, there are two pseudo-dialogs, one of which maintains a > registration for address A, and one of which maintains a registration > for address B. > > When a request reaches the proxy, since there are two contacts for the > request-URI, it forks the request to both UAs. If one UA accepts the > call (sends a 200 response), the proxy immediately CANCELs its forked > request to the other UA. This (usually) ensures that at most one > committed dialog is established for the incoming request. > > If both series of REGISTER messages used the same Call-Id, then they > would form only one pseudo-dialog, and only the contact in the most > recent REGISTER would be registered. In that case, an incoming > request would be sent to only one UA. > > Dale > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > -- Erol Turaç _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
