From: NandaKishoreE 71062 <[EMAIL PROTECTED]> The parameter will indicate which A/S in the cluster is handling that dialog. This parameter will be used by a router to route in-dialog messages to the corresponding A/S.
The problem comes when the A/S has crashed and the router needs to route a message to another A/S. It needs to route the message to some A/S2 & the parameter for that dialog needs to be modified accordingly. There is no header that can be reliably modified in an ongoing dialog. But within SIP, you can do nearly as well with this trick: For each A/S, establish a domain name. Each domain name has an SRV record at high priority for its A/S, and at lower priorities, SRV records for all of its cluster-mates. By standard RFC 3263 rules, a message sent to this domain name will go to its A/S if that A/S is functioning, and if that A/S is not functioning, the message will be routed to one of its cluster-mates. (Of course, a "smart" message router can be more clever, such as looking at the domain name and if its A/S is down, hashing the Call-Id to use as an index to select a backup A/S, thus ensuring that one backup A/S will handle all messages for any particular "stranded" dialog.) Then, whenever an A/S has to construct a Contact or Via header, and when it wants to apply a Record-Route header to a request it is forwarding, it uses this domain name. The A/S will recieve all appropriate messages as long as it is up, but if it goes down, the messages will be sent to its cluster-mates. This works correctly even if all other SIP agents in the network are just RFC 3261/3263-compliant. Unfortunately, many agents do not handle domain names in Via headers with the full RFC 3263 rules. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
