Gaurav Khare <gaurav.kh...@onmobile.com> writes: > I wanted to know if any unsupported parameter in SIP Header comes in > INVITE request which is not part of any SIP standard then while > framing the response is UAS obliged to include the same unsupported > parameter in the header ? > > For ex see below INVITE receiving and 180 Ringing sent, observe the > missing "yop" parameter from Via and Record-Route header in SIP 180 > Ringing message. UAS SIP stack doesn't understand the "yop" parameter > and hence discarded it. Can someone point me to any RFC section which > says clearly that whatever my UAS stack is doing is correct or not.
RFC 3261 section 12.1.1 "UAS behavior" says: When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. So in a 2xx response, the Record-Route value must contain all parameters. 3261 doesn't speak of the Record-Route headers in a 1xx response as establishing a route set, but in order to allow the UAC to send an UPDATE during the early dialog, it must do so. So the same rules must apply for Record-Route headers in 1xx responses as do in 2xx responses. As a general rule, when the SIP standards say that something must be copied, all optional parts of that thing must be copied with it, even if the copying entity doesn't know their meaning. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
