I agree.
Paul
Christer Holmberg (JO/LMF) wrote:
Hi,
IMO a Contact is required in all provisional responses except
for 100.
3261 definitely has the notion of early dialog which is
established by receipt of non-100 provisional response. (This
would be an unreliable provisional based on 3261, possibly
reliable based on extensions.)
The early dialog of course cannot be established without a
Contact. So either the establishment of the early dialog is
conditional on whether the provisional has the Contact or
not, or else the provisionals must always have the contact. I
don't recall any mention of this being conditional, so I
think the contact is always required.
In the "Summary of header fields" table of RFC3261 Contact is indicated
as "o" for 1xx responses. Whether that is because 1xx also covers 100
Trying, or because of some other reason, is unclear.
So, whatever option - mandating Contact in non-100, or allowing non-100
without Contact (which I assume means the early dialog will not be
established) - we choose, I think it needs clarification.
Maybe the easiest thing would be to say something like: "If the
provisional response is intented to establish an early dialog, it MUST
contain a Contact header."
Also, as I mentioned earlier, I think we need to clarify whether it's
allowed or not to "update" a previously sent Contact in a new 1xx or
2xx.
<---- 180 Contact=B
<---- 183 Contact=C
<---- 200 Contact=D
(the To tag has the same value in all 3 messages)
Regards,
Christer
Christer Holmberg (JO/LMF) wrote:
Hi,
At least in RELIABLE provisinal responses Contact is required, in
order to be able to send PRACK.
One of the issues we've been discussing before is whether an UAC is
allowed to send a non-CANCEL mid-dialog request once it has
received
an UNRELIABLE provisional response. I think the conclusion has been
that it IS allowed, and in that case a Contact of course
would be needed.
Whether we want to mandate Contact in unreliable
provisional responses
or not is one issue, but as part of the new
fix-the-bugs-in-3261 work
item it would give us an opportunity to clarify the issue.
Another, related, question which comes up every now and then: IF I
receive a provisonal response with a Contact, is it allowed
to "update"
that Contact in the 200 OK (or, another reliable resonse)? Whatever
the answer is, I think some clarification text would be useful.
Regards,
Christer
-----Original Message-----
From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED]
Sent: 26. toukokuuta 2007 13:52
To: [email protected]; [EMAIL PROTECTED]
Subject: Re: [Sip] Contact header in 1xx responses/updates remote
target ornot?
Dale,
Not sure if I read your comment right, but RFC3261 12.2.1.2 says
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.
It does not say anything about 1xx responses here
though...Regards,Jeroen [EMAIL PROTECTED] wrote:
From: Nina Garaca <[EMAIL PROTECTED]>
Q1: Should I expect that these responses have a Contact header?
As Paul says, if it didn't have a Contact header, it couldn't
establish a dialog.
Q2: If they do so, should the remote target of the dialog be
refreshed by that Contact at the side that has received that 1xx
response and should the remote target of the dialog be
refreshed by
the Contact in the INVITE request at the side that has
received that
INVITE?
Responses are not "target refresh requests", so they don't
change the
target address at their end of the dialog. But of course, the
responses to the dialog-initiating request establish the initial
target address.
Q3: If not, should the remote target of the dialog be
refreshed by
the Contact in the INVITE request
at the side that has received that INVITE and has
sent dialog
establishing 1xx response?
RFC 3261 section 12.2:
INVITE, the only target refresh request defined is
re-INVITE (see
Section 14). Other extensions may define different
target refresh
requests for dialogs established in other ways.
Dale
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[EMAIL PROTECTED] for questions on current sip Use
[EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[EMAIL PROTECTED] for questions on current sip Use
[EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[EMAIL PROTECTED] for questions on current sip Use
[EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
