> This is where I think the problem arises as the PRACK > is not within the DIALOG established by the 183.
The PRACK is within an established dialog. It is just indicating an incorrect remote target. > But the developer of the UAC is complaining that > the UAS is not responding with a 481. Why would the developer care? Did they intentionally send the incorrect request-URI hoping for a 481? It is an abnormal situation; thus the UAS can basically act however it wants. However since some vendors think that only 481 and 200 are valid final responses for PRACK, I would be interested to hear how they think the invalid PRACK should be handled since dialog and RAck are valid. <snip> > My questions are: > > MUST the UAC send the URI-Parameter Maybe; RFC 3261 section 19.1.4 is overly flexible concerning equality and allowing parameters to be dropped. However, dropping parameters typically causes interoperability issues. The UAC adding a user to the sip-uri is completely non compliant. The UAC needs to update the remote target with the 18x's Contact URI. RFC 3261 section 12.1.2: "The remote target MUST be set to the URI from the Contact header field of the response." > MUST the UAC not add a URI-Port when there is none in the CONTACT Yes; however RFC 2543 allowed the defaults to be optional within equality check. Thus some vendors might accommodate it for backward compatibility reasons. > MUST the UAS respond with a 481 to a PRACK when the DIALOG does not > match? It is irrelevant to the flow that was provided. The dialogs matched; the remote target was incorrect. It is an abnormal situation; thus the UAS can basically act however it wants. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
