Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt

From: [email-masked]
Date: Thu, 12 Jun 2008 23:05:30 -0400

From: "Francois Audet" <[email-masked]>

   I really think that this draft should make the inclusion of the original 
   non-2XX final response in the 199 MANDATORY by the forking proxy. This would
   be in a message/sip body as described in sectin 23.4/RFC 3261.

(This is outside the scope of the I-D itself.)

If we envision having the 199 carry information from the associated
failure response, I suggest we use a message/sipfrag body excerpted
from the failure response, rather than copying headers from the
failure response into the 199's headers, or copying the entire failure
response as the body of the 199.

The syntax of sipfrag is unambiguous but extremely flexible (RFC
3420):

           sipfrag = [ start-line ]
                     *message-header
                     [ CRLF [ message-body ] ]

Essentially, it is any subset of the headers of the response,
optionally followed by the body.  This subsetting capability allows
small responses (e.g., omit the Via's, Call-Id, To, From,
Record-Route's, etc.), as well as making topology-hiding
straightforward.

It's also inherently extensible, in that if a proxy/UAS decides to add
more headers to the sipfrag, the UAC knows how to identify and/or
ignore them.

It's also terse, in that carrying any header from the response in a
message/sipfrag body is no longer than carrying it as a header of the
199 response.

Dale
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 12 Jun 2008 20:23:29 -0700

And do you think we should specify what are the minimum headers thatshould
be carried?

What about MIME bodies?

There might be cases where they are really important, no?

I'm a little worried that the proxy may remove important information.
Especially when we extend SIP.

Maybe instead we should list the removable headers (e.g., all the ones that
are identical to their counterpart in the 199 itself), and then explain
"don't remove what you don't understand"?

Opinions?

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 13 Jun 2008 12:50:20 +0200

Hi,

I assume there aren't going to be that many headers in the non-2xx error response, and I think most will be identical to what will be used in the 199 anyway - To, From, Call-ID etc.

I am ok with also talking about SIP headers, in addition to response code and possible SDP body, but I don't think we should make this too complex.

And, to answer Dale, the intention IS to use sipfrag - no matter how much/little information of the final response we include in the 199.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Audet
Sent: 13. kesäkuuta 2008 6:23
To: [email-masked]; SIP IETF
Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt

And do you think we should specify what are the minimum headers thatshould be carried?

What about MIME bodies?

Maybe instead we should list the removable headers (e.g., all the ones that are identical to their counterpart in the 199 itself), and then explain "don't remove what you don't understand"?

Opinions?

On Jun12 2008 20:05 , "[email-masked]" <[email-masked]>
wrote:

> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip

This list is for NEW development of the core SIP Protocol Use [email-masked] for questions on current sip Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Jun 2008 10:39:31 -0400

My first thought was to agree with Dale, and in fact I already suggested 
use of sipfrag. But I already have experience from the refer NOTIFY that 
sipfrag info is difficult to take advantage of if you have no guarantee 
of what will be included.

IIRC this 199 work was explicitly not expected to solve the full HERFP 
problem. Yet if it could serve for that it would be a good thing. Its 
just that thrashing out everything that is needed will take a bunch of time.

Also, sending back the whole message will make more data to send in 
cases where it often isn't useful.

We could allow a body containing *either* message/sip or 
message/sipfrag, and make them both conditional on presence of a 
corresponding Accept header in the request. If there was no Accept 
header for either then no body would be included. If there was an accept 
for both, message/sip would be be preferred. When a sipfrag is returned 
in a 199, we could require that it include at least the header line, and 
the rest would be at the discretion of the proxy.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 13 Jun 2008 12:15:05 -0500

> cases where it often isn't useful.

It is also likely to break UDP. See the problems we had with diagnostic 
responses in general.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 14 Jun 2008 14:52:45 +0200

Hi,
 
I think Paul's suggestion sounds good. I think it's also alligned with what Francois suggested earlier, to say "MUST include response code".
 
Regards,
 
Christer

________________________________

From: [email-masked] on behalf of Paul Kyzivat
Sent: Fri 13/06/2008 16:39
To: Francois Audet
Cc: SIP IETF
Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt

        Paul

---

From: Bob Penfield <[email-masked]>
Date: Tue, 17 Jun 2008 19:32:10 -0400

Some comments on this draft. I apologize if they are duplicates.

Section 5 should only allow the UAS to send a 199 if it sent a dialog creating (101-199) provisional response. I know its implicit, but needs to be explicitly stated to prevent extra traffic. Suggest something like this:

   When a UAS wants to terminate an INVITE server transaction it sends a non-2xx
   SIP final response, as specified in [RFC3261].  In addition, if the UAS has
   previously sent a dialog creating 1xx response (101-199) for the transaction,
   then prior to sending the non-2xx SIP final response, the UAS MAY send a 199
   response to indicate that the early dialog is being terminated. The 199 response
   MUST have the same tag in the To header as sent in the dialog creating 1xx
   response.

In section 6 requires a forking proxy to send 199s for all early dialogs associated with the non-2xx response. However, if there are multiple forking proxies along the path (or some UASs send 199s), that could result in multiple 199's for a given dialog. IMO, if the proxy has already forwarded a 199 for a given dialog, it should not send one of its own.

On the topic of UAS's sending 199, I actually think things will work better if they did. I know there has been lots of discussion about B2BUAs doing it, but consider a UAS that is aware that it has multiple registered contacts (via presence or registration event package or other means), it might want to send the 199 to be sure that it does reach the UAC (in case the proxy does not support it).

Section 8 Open Issues:

IMO, the 199's To-tag should identify the dialog being terminated.

IMO, the 199's body MAY contain message/sipfrag with the non-2xx response code and important headers like Warning.

cheers,
(-:bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, May 23, 2008 1:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

        Title           : Response Code for Indication of Terminated Dialog
        Author(s)       : C. Holmberg
        Filename        : draft-ietf-sip-199-00.txt
        Pages           : 9
        Date            : 2008-5-15

This specification defines a new SIP response code, 199 Early Dialog
   Terminated, which a SIP entity can use to indicate upstream that an
   early dialog has been terminated.  The response code can be used by a
   SIP entity, normally a forking SIP proxy, to allow the UAC to know
   that an early dialog has been terminated before it a final response
   is sent to the request.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-199-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Jun 2008 23:44:11 -0400

> On the topic of UAS's sending 199, I actually think things will work better if they did. I know there has been lots of discussion about B2BUAs doing it, but consider a UAS that is aware that it has…

Bob, I don't understand the point you are making. Can you explain further?

Are you talking about a case where there is a forking proxy in front of 
the UAS, and the proxy doesn't know about 199, and the UAS wants to send 
the 199 to give the UAC a warning in case the final response is delayed 
by the proxy?

While there may be some cases where that would be advantageous, in many 
others it would just increase the message traffic for every failing 
call. And I don't see how the UAS would be able to discern the cases 
where it would be advantageous. I guess it could be configured in those 
cases where all inbound calls are forked, but how many such cases are there?

	Paul

---

From: Bob Penfield <[email-masked]>
Date: Wed, 18 Jun 2008 08:03:33 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, June 17, 2008 11:44 PM
> To: Bob Penfield
> Cc: [email-masked]
>> On the topic of UAS's sending 199, I actually think things will work
>> better if they did. I know there has been lots of discussion about
>> B2BUAs doing it, but consider a UAS that is aware that it has multiple
>> registered contacts (via presence or registration event package or
>> other means), it might want to send the 199 to be sure that it does
>> reach the UAC (in case the proxy does not support it).
>

Yes, that is pretty much the case I was considering.

> cases where all inbound calls are forked, but how many such cases are there?

If the UAS knows that the AOR has multiple registered contacts, it knows that inbound calls will be forked. In that case, it could send the 199. As long as proxies don't generate 199s in addition to ones they forward, the increased traffic could be limited.

Having proxies generate responses on behalf of a UAS is a bit of a violation of the end-to-end principle from a purist point of view. By certainly having only proxies generate 199s would limit the increase in messages.

I was just trying to point out that there might be cases where real User Agent would send 199 and not just B2BUAs.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Jun 2008 08:33:47 -0400

> If the UAS knows that the AOR has multiple registered contacts, it knows that inbound calls will be forked. In that case, it could send the 199. As long as proxies don't generate 199s in addition t…

How often does a UAS know that there are multiple contacts for this AOR?

Even if it does, it presumably can't know if it is the last one tried, 
the first, or whatever.

> Having proxies generate responses on behalf of a UAS is a bit of a violation of the end-to-end principle from a purist point of view. By certainly having only proxies generate 199s would limit the…

Yes, it is.

> I was just trying to point out that there might be cases where real User Agent would send 199 and not just B2BUAs.

I do appreciate the point that there *can* be cases where the UAS would 
have enough info to justify sending a 199 response. But the cases where 
a UAS is likely to know that in practice seem limited, with the 
exception of B2BUAs. I would just like to avoid giving UA developers the 
idea that they *ought* to be generating 199 responses on a regular 
basis. Doing so "to be helpful" is likely to be sub-optimal in many cases.