Raymond Dans wrote: > Hi all, > In looking at Call Detail Recording, I ran into an issue where > records were not being closed off in abandoned call scenarios. Upon > closer investigation, I noticed that a call failure state event wasn't > being generated in the Proxy because of an apparent change in the 408 > Request Timeout SIP message. The criteria for generating a call > failure state event in this scenario was to look at the "To tag" of the > 408 Request Timemout message. If it was nil then the event was > generated and otherwise it was not. > > In SipXecs 3.10.x, the abandoned scenario would have a nil "To tag" > so the CDR record was correctly closed off. In 3.11.5, the "To tag" in > this scenario is not nil and as a result the record is never closed off > and appears in the active calls list for some time (around 8 hours). > > Deos anyone know if the change in the 408 message was intentional or > is this a bug that should be reported. Looking at the RFC doesn't > really give a clear answer (to me anyways) as to whether or not the > ToTag should be present. >
I believe the behavior is correct. RFC 3261 Section 8.2.6.2. states "If a request contained a To tag in the request, the To header field in the response MUST equal that of the request. However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present). This serves to identify the UAS that is responding, possibly resulting in a component of a dialog ID. The same tag MUST be used for all responses to that request, both final and provisional (again excepting the 100 (Trying))." So as far as I understand, any responses (except 100 Trying) to a Request MUST contain a to-tag. If there was a to-tag already present in the Request then you must echo that, otherwise you MUST generate a new one and include that. Arjun _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
