Hemant, It is an implementation decision whether or not a UA wants to attempt to reconstitute dialogs after a crash and restart. It is possible to do this based soley on the information in SIP messages received after the restart, no permanent database required. Some relevant RFC3261 text:
12.2 Requests within a Dialog <snip> 12.2.2 UAS Behavior <snip> If the request has a tag in the To header field, but the dialog identifier does not match any existing dialogs, the UAS may have crashed and restarted, or it may have received a request for a different (possibly failed) UAS (the UASs can construct the To tags so that a UAS can identify that the tag was for a UAS for which it is providing recovery). Another possibility is that the incoming request has been simply misrouted. Based on the To tag, the UAS MAY either accept or reject the request. Accepting the request for acceptable To tags provides robustness, so that dialogs can persist even through crashes. UAs wishing to support this capability must take into consideration some issues such as choosing monotonically increasing CSeq sequence numbers even across reboots, reconstructing the route set, and accepting out-of-range RTP timestamps and sequence numbers. <snip> The last sentence above mentions reconstructing the route set, which is done by using Record-Route headers added by proxies in the requests within the dialog, along with the latest Contact. John Hearty Level3 -----Original Message----- From: Hemant Pandey [mailto:[EMAIL PROTECTED] Sent: Thursday, March 06, 2003 1:11 AM To: Hearty, John; [EMAIL PROTECTED] Subject: Re: [Sip-implementors] RE: Significance of Route, Record-Route and Path Header Field Hi John, In case,if a UA has crashed and restarted then all the dialogs and its related states should be distroyed.In that case UA has to send INVITE again to establish dialog and intermediate SIP element again add Record-Route Header field. If i consider your point of view, in that UA should have some permanent database in which UA can store dialog state. so that when it restart it reads dialog state from that database and send that request. In this case also UA can use route set value of the database, and send this request within dialog. So i do not understand your view.Please explain it in more detail. Thanxs & Regards Hemant ----- Original Message ----- From: Hearty, John To: Hemant Pandey ; [EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 9:46 PM Subject: RE: [Sip-implementors] RE: Significance of Route, Record-Route and Path Header Field Proxies may add Record-Route to requests within a dialog if they wish to remain in the dialog in the event a UA has crashed and restarted. John Hearty -----Original Message----- From: Hemant Pandey [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 8:34 PM To: Chris Boulton; [EMAIL PROTECTED] Subject: Re: [Sip-implementors] RE: Significance of Route, Record-Route and Path Header Field Hi All, As per the definition of Record-Route Header field given in the RFC3261, Record-Route Header field should be added only in the Request that initiates the dialog. Request within dialog has no use of this header field. Because while establishing dialog both peer UAs has stored Recod-Route field values in the dialog state as route-set. So in the request within dialog, UAs can use these values to form Route Header field and there is no use of Record-Route Header field. Then why in the RFC3261, it is mentioned that request within dialog MAY have Record -Route Header field.while it is discarded at the peer UA. Is there any reason to maintain this? Can't Record-route Header field be deleted from request within dialog.because RFC 3261 has already categorized request out of dialog and reqest within dialog? Regards Hemant ----- Original Message ----- From: Chris Boulton To: Hemant Pandey ; [EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 4:42 PM Subject: [Sip-implementors] RE: Significance of Route, Record-Route and Path Header Field Hemant, Record route and route headers are tightly linked. A session could be initiated through a SIP proxy server but subsequent transactions will travel directly between User Agents. This will result in the SIP proxy server not seeing requests such as BYE or Re-INVITE. This makes it impossible for entities that maybe want to bill calls or keep call state for the entire call duration. Record route is used a 'stamping' mechanism so that SIP proxies that see a request can view all related (subsequent) requests. The record route header is then used by the endpoints to construct a route set. This route set is then constructed at endpoints and followed for subsequent requests, rather than sending direct. Record-route and route header fields are separated as they are constructed independently at UAS/UAC - they have to be separated. If any of these header fields are missing, the proxy will not be traversed by subsequent requests. Path has a very similar function to Record route and was designed for use with 3GPP implementations. It's purpose is solely to allow requests to be routed to an endpoint once a lookup has been done on a registration, ensuring correct proxies are visited on the way (Forcing them to visit and not got directly to client). The two are needed as Record route can not be used with the Register request due to backward compatibility issues. Regards, Chris. -----Original Message----- From: Hemant Pandey [mailto:[EMAIL PROTECTED] Sent: 04 March 2003 10:18 To: Chris Boulton; [EMAIL PROTECTED] Subject: Significance of Route, Record-Route and Path Header Field Hi All I am confused between Route, Record-Route and path Header fields.I am not able to understand their significance and their need in different SIP messages. It seems the these header fields contain duplicate copy of same information. Could any one help me out to understand significance of these Header fields? Why and when these different Header fields required? Can't a single Header field (Route or Record-Route or Path) solve the purpose of all three header fields? what problems will arise if any one of these header field is missing? I need ur cooperation to understand these points. Regards Hemant _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
