Hi,
This may be more a SIP question than a Kamailio question, but I am trying to figure out why 407 challenges from Kamailio contain To tags.
I suppose I've not run across it before, and I can't find an RFC-based rationale. A negative reply to an invite transaction without an intermediate early dialog-forming reply (e.g. 183 with To tag) does not form a dialog, nor takes place within a context in which a dialog was created. So what gives?
Insights appreciated!
-- Alex
Am Montag, 26. März 2018, 16:55:12 CEST schrieb Alex Balashov:
This may be more a SIP question than a Kamailio question, but I am trying to figure out why 407 challenges from Kamailio contain To tags.
I suppose I've not run across it before, and I can't find an RFC-based rationale. A negative reply to an invite transaction without an intermediate early dialog-forming reply (e.g. 183 with To tag) does not form a dialog, nor takes place within a context in which a dialog was created. So what gives?
Hello Alex,
its indeed that common that it also included in the example RFC 3665, section 3.3. and other.
There is a transaction relationship between the INVITE and the 407. RFC 5057 mandates that the 407 only refers to the transaction, not to any dialog state. But you are right, if there is no provisional response, there is no (early) dialog at this state.
But its also included in the 401 (for REGISTERs).
I would think this is normal UAC/UAS behavior for SIP request handling:
RFC 3261, sect. 8.2.6.2: "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. "
Or I am wrong?
Henning
On Mon, Mar 26, 2018 at 10:27:35PM +0200, Henning Westerholt wrote:
I would think this is normal UAC/UAS behavior for SIP request handling:
RFC 3261, sect. 8.2.6.2: "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. "
Honestly, in ten years of doing SIP, this is the first time I am confronting this question. I was accustomed to the notion that To tags are only added to a reply when it is desirable to form an early dialog (in the case of a non-100 1xx reply). But the passage you quote seems to settle it.
Le 2018-03-26 à 22:49, Alex Balashov a écrit :
On Mon, Mar 26, 2018 at 10:27:35PM +0200, Henning Westerholt wrote:
I would think this is normal UAC/UAS behavior for SIP request handling:
RFC 3261, sect. 8.2.6.2: "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. "
Honestly, in ten years of doing SIP, this is the first time I am confronting this question. I was accustomed to the notion that To tags are only added to a reply when it is desirable to form an early dialog (in the case of a non-100 1xx reply). But the passage you quote seems to settle it.
An additional question! Does second authenticated INVITE sent by UAC should also mention this to tag and the called UA should also accept it as part of the dialog id ?
Or does the second authenticated INVITE open a new dialog ?
Emmanuel
Am Dienstag, 27. März 2018, 15:30:01 CEST schrieb Emmanuel BUU:
[..]
Honestly, in ten years of doing SIP, this is the first time I am confronting this question. I was accustomed to the notion that To tags are only added to a reply when it is desirable to form an early dialog (in the case of a non-100 1xx reply). But the passage you quote seems to settle it.
An additional question! Does second authenticated INVITE sent by UAC should also mention this to tag and the called UA should also accept it as part of the dialog id ?
Or does the second authenticated INVITE open a new dialog ?
Hello Emmanuel,
the first dialog is created at the second successful INVITE. The second INVITE is just a re-send of the first INVITE with the authentication credentials. To quote from RFC 3261, section 12.1:
Creation of a Dialog Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog. A dialog established by a non-final response to a request is in the "early" state and it is called an early dialog.
You will find a good example for a sessions establishment including authentication and two proxies in RFC 3665, section 3.2.
Best regards,
Henning
-
Alex Balashov -
Emmanuel BUU -
Henning Westerholt