12.2.1.2 Processing the Responses
The UAC will receive responses to the request from the transaction layer. If the client transaction returns a timeout, this is treated as a 408 (Request Timeout) response.
The behavior of a UAC that receives a 3xx response for a request sent within a dialog is the same as if the request had been sent outside a dialog. This behavior is described in Section 8.1.3.4.
Note, however, that when the UAC tries alternative locations, it still uses the route set for the dialog to build the Route header of the request.
When a UAC receives a 2xx response to a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present.
https://www.rfc-editor.org/rfc/rfc3261#section-12.2.1.2
20.10 Contact
A Contact header field value provides a URI whose meaning depends on the type of request or response it is in.
A Contact header field value can contain a display name, a URI with URI parameters, and header parameters.
This document defines the Contact parameters "q" and "expires". These parameters are only used when the Contact is present in a REGISTER request or response, or in a 3xx response. Additional parameters may be defined in other specifications.
When the header field value contains a display name, the URI including all URI parameters is enclosed in "<" and ">". If no "<" and ">" are present, all parameters after the URI are header parameters, not URI parameters.
https://www.rfc-editor.org/rfc/rfc3261#section-20.10
On Thu, Mar 9, 2023 at 6:00 PM Benoit Panizzon benoit.panizzon@imp.ch wrote:
Hi Daniel, Alex and all
I'm having an argument with the Vendor of our SBC towards IC carriers.
According to $vendor tech, if the SIP Message was received via UDP, the transport= attribute of the Contact Header has no meaning and therefore the RURI of a following transaction (like BYE) will not contain a transport attribute as the reply is sent via UDP.
This of course breaks communication CPE behind a kamailio proxy which are connected via TCP or TLS.
I've been looking through RFC3261 and I find various examples how the transport attribute can be used.
But I fail to find, that a transport received in the Contact header MUST be re-used in the RURI of subsequent transactions within one dialogue.
From my point of view, this is logical and this is how various devices I have tested operate. But with a commercial vendor, if it's not in the RFC it's no Bug and won't be fixed... Does anyone know in which section (or maybe other RFC) this is covered?
Mit freundlichen Grüssen
-Benoît Panizzon-
I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: