Subject: [Sipping] draft-holmberg-sipping-199-00.txt

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 15 Mar 2007 10:30:19 +0100

Hi,

I've put together the first version of the 199 response code draft,
based on my initial idea and the discussions on the mailing list. It
defines a new response code, which can be used by forking proxies to
indicate that a specific early dialog has been terminated.

You can find it at:
http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-199-00.txt

Regards,

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

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 15 Mar 2007 11:01:32 -0500

Is the target recipient of this 199 the UAC or the forking proxy?

It would seem that the UAC doesn't know its request has been forked, 
and the forking proxy may have more the remaining forks ignored, 
which may leave some entities in an interesting state of "I know this 
branch X responded - but with a no, but the other branches Y and Z 
aren't responding".  What's supposed to happen - and after how long? 
I think a CANCEL is sent on the other branches after some timeout, 
right? Shouldn't this draft say explicitly that (no matter how 
obvious this is to some), or something else you are wanting to occur?

(the obviousness factor could be way up here)

At 04:30 AM 3/15/2007, Christer Holmberg \(JO/LMF\) wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C766E4.8C242ABA"
>
>
>Hi,
>
><http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-199-00.txt>http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-199-00.txt 
>
>
>Regards,
>
>Christer

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 15 Mar 2007 11:10:27 -0500

Hi Christer,

Can you explain why this is different/better than the proposed 130 error

response code?

http://tools.ietf.org/html/draft-mahy-sipping-herfp-fix-01

It seems to me that the 199 proposal does not address some of the issues
that
the 130 header addresses. For example, because 130 carries the value of
the
original non-200 final response, it allows the UAC to take proper action
if
required. For example, if it includes a value indicating a failure that
can
be corrected, the UA may re-initiate the call.

________________________________

	From: Christer Holmberg (JO/LMF)
[mailto:[email-masked]] 
	Sent: Thursday, March 15, 2007 02:30
	To: IETF Sipping List
	Cc: Paul Kyzivat
	Subject: [Sipping] draft-holmberg-sipping-199-00.txt

	Hi, 

	I've put together the first version of the 199 response code
draft, based on my initial idea and the discussions on the mailing list.
It defines a new response code, which can be used by forking proxies to
indicate that a specific early dialog has been terminated.

	You can find it at:
http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-199-00.txt
<http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-199-00.tx
t>  

	Regards, 

	Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 15 Mar 2007 18:47:08 +0100

Hi Francois,

I have to admit I had forgotten about the 130 response code. If it is
used for the same purpose I see no reason why it couldn't be used.

The drafts do have some differences regarding the PRACK and offer/answer
procedures, but that is something which can be discussed.

The -01 version of the draft has expired, though. Rohan, are you
planning to update it? If so, I would be happy to help you.

Regards,

Christer

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: 15. maaliskuuta 2007 18:10
> To: Christer Holmberg (JO/LMF); IETF Sipping List
> Cc: Paul Kyzivat
> Subject: RE: [Sipping] draft-holmberg-sipping-199-00.txt
> 
> Hi Christer,
> 
> It seems to me that the 199 proposal does not address some of 
> the issues that the 130 header addresses. For example, 
> because 130 carries the value of the original non-200 final 
> response, it allows the UAC to take proper action if 
> required. For example, if it includes a value indicating a 
> failure that can be corrected, the UA may re-initiate the call.
> 
> 	I've put together the first version of the 199 response 
> code draft, based on my initial idea and the discussions on 
> the mailing list.
> It defines a new response code, which can be used by forking 
> proxies to indicate that a specific early dialog has been terminated.
> 
> 	You can find it at:

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 15 Mar 2007 18:48:14 +0100

Hi James, 

>Is the target recipient of this 199 the UAC or the forking proxy?

The UAC.

I guess I could have included an example call flow.

>It would seem that the UAC doesn't know its request has been forked,

It does know, if it has received provisional responses with different To
tag values, ie it has established multiple early dialogs. 199 would only
be sent for established early dialogs.

>and the forking proxy may have more the remaining forks ignored, which
may leave some entities in an 
>interesting state of "I know this branch X responded - but 
>with a no, but the other branches Y and Z aren't responding". 
>What's supposed to happen - and after how long? 

If a branch does not respond, no early dialog is created, and no 199
will be sent.

Again, 199 is only sent for early dialogs, when the early dialog is
terminated, normally when the forking proxy receives a final error
response. But, since the forking proxy does not always forward the final
error response (it waits for responses for other branches) it uses 199
to indicate to the UA that the early dialog (the early dialog on which
the forking proxy received the final error response) has been
terminated.

>I think a CANCEL is sent on the other branches after some 
>timeout, right?

Yes.

>Shouldn't this draft say explicitly that (no matter how obvious this is
to some), or something else you 
>are wanting to occur?

I think the draft does talk about the CANCEL, but I will check whether
it can be better clarified.

Thanks for your comments!

Regards,

Christer

> ><http://users.piuha.net/cholmber/drafts/draft-holmberg-sippin
> g-199-00.t
> >xt>http://users.piuha.net/cholmber/drafts/draft-holmberg-sipp
> ing-199-00
> >.txt
> >
> >
> >Regards,
> >
> >Christer
> >This list is for NEW development of the application of SIP Use 
> >[email-masked] for questions on current sip Use 
> >[email-masked] for new developments of core SIP
>

---

From: [email-masked]
Date: Thu, 15 Mar 2007 13:31:17 -0500

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>

I'd like to suggest that you use a different number than 199.  That is
because I've always mentally reserved the x99 response codes as the
ones that will be the special "extended response codes" when we run
out of response codes in each category.  Didn't you initially pick
190?

Dale

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 15 Mar 2007 19:39:39 +0100

Hi, 

>I'd like to suggest that you use a different number than 199. 
>That is because I've always mentally reserved the x99 
>response codes as the ones that will be the special "extended 
>response codes" when we run out of response codes in each 
>category.  Didn't you initially pick 190?

Yes, I did, in fact...

Anyway, I don't mind using 190 :) And, if we decided to put it all in
Rohan's 130 draft (see Francois' mail), I guess 130 would also be one
option.

Regards,

Christer

---

From: [email-masked]
Date: Thu, 15 Mar 2007 14:34:18 -0500

Some suggestions for this draft:

* Change default response test from "Dialog Terminated" to "Early
  Dialog Terminated"

* The definition of 199 cannot ignore the question of identifying
  media streams.  For example, suppose a proxy forks to two UAs, but
  both UAs are on the same host, and use the same port to send early
  media.  Then one UA terminates its dialog and sends a 199.  There is
  no way for the UAC to determine whether or not it should continue to
  render media arriving from the observed host/port, because it has
  no way to determine which UA is sending the media.  (And this is all
  the worse because the UAC has no idea what the UASs are, what hosts
  they are on, or what host(s)/port(s) they are sending media from, or
  how they correlate.)

  In order to avoid this problem, we need to add some rules for SDP:

  If the session is described by a body of type application/sdp, then:

  A UAS sending a 199 for an early dialog:

  - SHOULD have sent the early dialog's media from the host(s)/port(s)
  specified by the c= and m= line(s) of the SDP it sent

  - MUST ensure that no other dialog's media is sent from those
  host(s)/port(s)

  - SHOULD send no more media for that early dialog

  - MUST be willing to not have rendered any media that was sent after
  the 199 was sent

  A UAC that receives a 199 for an early dialog:

  - MAY cease rendering any media sent from the host(s)/port(s)
  specified by the c= and m= line(s) of the SDP it received for that
  early dialog

* "A 199 Dialog Terminated provisional response MUST NOT contain an SDP
  offer/answer message body."

  I would suggest that this be reduced to SHOULD, as I can see a use
  for including SDP that we might discover is desirable:  The SDP for
  the early media may not have arrived at the UAC, and if not, the UAC
  cannot determine from the 199 alone what media source (host/port) to
  ignore.  Hence, it might be useful if the 199 contains a copy of the
  SDP that the UAS sent.  (I am not suggesting standardizing that
  action, but we want to ensure that nobody writes an implementation
  that will fail if we eventually do standardize that action.)

* In regard to support by proxies:

  We also need to allow for the situation where the UAS understands
  199 but not the proxy.  It seems to me that the best solution is:

  - When a UAS has sent early media, and is going to send a failure
  final response, it SHOULD first send a 199 response.  (If the proxy
  does not understand 199, it will forward the 199 to the UAC anyway;
  the final response will not stimulate it to send a 199.)

  - A proxy SHOULD follow these rules:

    + For each forking, it MUST retain knowledge of the early dialogs
      for which it has forwarded 199 responses upstream.

    + If a fork returns a failure final response, and if the proxy has
      not forwarded a 199 response for that early dialog, the proxy
      MUST construct and send a 199 response upstream for that early
      dialog.

  This ensures that exactly one 199 is sent upstream if either the
  proxy or the UAS or both implements 199.

* "Since all SIP entities involved in a session setup do not
  necessarily support the specific meaning of the 199 Dialog
  Terminated provisional response, the sender of the response MUST be
  prepared to receive SIP requests associated with the dialog for
  which the 199 response was sent."

Add: "A UAC that receives a 199 for an early dialog SHOULD NOT send
any further requests to that dialog (even before a response is
received that terminates the dialog)."

Dale

---

From: [email-masked]
Date: Thu, 15 Mar 2007 15:39:37 -0500

My memory is that 130 is meant to solve distinctly different problems,
so the recommendations as to when a response "should" be generated are
probably different.  But it's possible that the two proposals can be
folded together into one mechanism that satisfies both sets of
requirements.

Dale

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 15 Mar 2007 22:11:16 +0100

Hi, 

>My memory is that 130 is meant to solve distinctly different 
>problems, so the recommendations as to when a response 
>"should" be generated are probably different.  But it's 
>possible that the two proposals can be folded together into 
>one mechanism that satisfies both sets of requirements.

I agree.

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 16 Mar 2007 16:01:14 +0100

Hi Dale, 

>* Change default response test from "Dialog Terminated" to "Early

I can do that.

>  they are on, or what host(s)/port(s) they are sending media from, or

I am not saying this doesn't need to be solved, but I think it's a
separate and more generic (you can have this problem even without 199)
issue and should not be solved in this draft. Maybe it should be treated
as part of the early media discussion?

>   specified by the c= and m= line(s) of the SDP it sent

Does that help if you have a NAT in the media path?

>   - MUST be willing to not have rendered any media that was sent after

I am not sure I understand the last statement. The UAS probably doesn't
know that a 199 has been sent. The UAS sends an error final response,
and the forking proxy sends the 199.

So, the requirement should say that the UAS MUST be willing to not have
rendered any media that was sent after the error final response was sent
- but I think that's quite obvious (I don't even think the UAS will send
any media after the error final response has been sent).

>   specified by the c= and m= line(s) of the SDP it received for that

I think that is covered by the statement saying that the UAC may release
resources associated with the early dialog.

>   that will fail if we eventually do standardize that action.)

Ok, I agree that sending a "copy" of a previou SDP is ok. What I had in
mind when writing the text was that a NEW offer or answer should not be
inserted in the 199.

>   proxy or the UAS or both implements 199.

I hear what you are saying, but sending a 199 directly followed by the
error final response doesn't sound very effective to me...

It would of course be good if the UAS could check whether the forking
proxies in the path support 199 or not. However, it doesn't help to e.g.
define a Via/Record-Route header parameter for that, because you can't
see from the Via/Record-Route set which proxy did the forking. We would
need to define such parameter Via also. 

> Add: "A UAC that receives a 199 for an early dialog SHOULD 
> NOT send any further requests to that dialog (even before a 
> response is received that terminates the dialog)."

I think we can have a MUST NOT send.

Regards,

Christer

---

From: [email-masked]
Date: Fri, 16 Mar 2007 13:02:28 -0500

That's what makes the problem "interesting"...  We can say that the
UAC may release resources associated with the early dialog, but we
don't really mean that it can just forget about the early dialog.
What we *mean* is that it can stop rendering the media associated with
the early dialog (and release any resources being held to render any
further media for that early dialog).

But if you think about it, in SIP there is no way to associate an
incoming media stream with a particular early dialog -- all incoming
media streams use the c= address in your SDP, and there is no
restriction on the address from which the media can come.

So there has to be a way to correlate early dialogs and media streams.
And as far as I can tell, this has to be an extension (a restriction
on UAs' behavior) associated with response 199.

If that is so, only the UA can generate 199, as only it knows that it
is obeying those restrictions.

Dale

---

From: [email-masked]
Date: Fri, 16 Mar 2007 13:06:02 -0500

We don't *need* to be so strict, as the 199 might get lost before it
reaches the UAC, so everybody downstream must be prepared to cope with
"late" requests.  OTOH I can't see any possible use for a UAC
knowingly sending such a request, as RFC 3261 mandates a 481
response.

Dale

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sun, 18 Mar 2007 19:13:04 +0100

Hi, 

>>I think that is covered by the statement saying that the 
>>UAC may release resources associated with the early dialog.
> 
>That's what makes the problem "interesting"...  We can say 
>that the UAC may release resources associated with the early 
>dialog, but we don't really mean that it can just forget 
>about the early dialog.
>
>What we *mean* is that it can stop rendering the media 
>associated with the early dialog (and release any resources 
>being held to render any further media for that early dialog).
> 
>But if you think about it, in SIP there is no way to 
>associate an incoming media stream with a particular early 
>dialog -- all incoming media streams use the c= address in 
>your SDP, and there is no restriction on the address from 
>which the media can come.
> 
>And as far as I can tell, this has to be an extension (a 
>restriction on UAs' behavior) associated with response 199.
> 
>If that is so, only the UA can generate 199, as only it knows 
>that it is obeying those restrictions.

I wouldn't mind to start working on a mechanism to associate media
streams with dialogs. But, again, I don't think we should do it within
this draft, because I think it would be useful even without 199. I think
it should either be done as part of the early media work, or as a
separate work item.

It will also most likely require some co-operation witFrom [email-masked] Sun Mar 18 14:15:39 2007
Content-class: urn:content-classes:message
Subject: RE: [Sipping] Re: draft-holmberg-sipping-199-00.txt
Date: Sun, 18 Mar 2007 19:13:04 +0100
From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
To: <[email-masked]>,
	<[email-masked]>
Cc: 

Hi, 

>>I think that is covered by the statement saying that the 
>>UAC may release resources associated with the early dialog.
> 
>That's what makes the problem "interesting"...  We can say 
>that the UAC may release resources associated with the early 
>dialog, but we don't really mean that it can just forget 
>about the early dialog.
>
>What we *mean* is that it can stop rendering the media 
>associated with the early dialog (and release any resources 
>being held to render any further media for that early dialog).
> 
>But if you think about it, in SIP there is no way to 
>associate an incoming media stream with a particular early 
>dialog -- all incoming media streams use the c= address in 
>your SDP, and there is no restriction on the address from 
>which the media can come.
> 
>And as far as I can tell, this has to be an extension (a 
>restriction on UAs' behavior) associated with response 199.
> 
>If that is so, only the UA can generate 199, as only it knows 
>that it is obeying those restrictions.

I wouldn't mind to start working on a mechanism to associate media
streams with dialogs. But, again, I don't think we should do it within
this draft, because I think it would be useful even without 199. I think
it should either be done as part of the early media work, or as a
separate work item.

It will also most likely require some co-operation with other WGs, like
AVT and MMUSIC, which don't really care about the 199 response code as
such.

The problem with trying to solve everything within a single draft is
that it is difficult to focus, and it will take ages to produce
anything. Let's separate the things.

Because, in some cases 199 may be useful to peopleeven if they don't
know whe IP source information etc for a stream associated with the
early dialog. "Resource" may have different meaning for different
applications, access types and network architectures.

Regards,

Christer

> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sun, 18 Mar 2007 19:13:18 +0100

Hi, 

>>>which the 199 response was sent.h other WGs, like

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sun, 18 Mar 2007 19:13:18 +0100

Hi, 

>We don't *need* to be so strict, as the 199 might get lost 
>before it reaches the UAC, so everybody downstream must be 
>prepared to cope with "late" requests.

Yes.

But, IF the UAC DOES receive the 199, and understands the meaning of it,
I still see no reason why it should send anything. Eventhough network
entities shall be prepared to receive requests on the dialog, from the
UAC perspective the dialog is terminated - even we don't send messages
on non-existing dialogs :)

>OTOH I can't see any possible use for a UAC knowingly sending such a
request, as RFC 3261 mandates a 481 response.

Exactly.

Regards,

Christer

"
>We don't *need* to be so strict, as the 199 might get lost 
>before it reaches the UAC, so everybody downstream must be 
>prepared to cope with "late" requests.

Yes.

But, IF the UAC DOES receive the 199, and understands the meaning of it,
I still see no reason why it should send anything. Eventhough network
entities shall be prepared to receive requests on the dialog, from the
UAC perspective the dialog is terminated - even we don't send messages
on non-existing dialogs :)

>OTOH I can't see any possible use for a UAC knowingly sending such a
request, as RFC 3261 mandates a 481 response.

Exactly.

Regards,

Christer