Subject: RE: [Sipping] draft-holmberg-sipping-199-02

From: "Elwell, John" <[email-masked]>
Date: Mon, 02 Jul 2007 10:21:37 +0100

> >>>Lastly, if dialogs are formed using a reciprocal request(UPDATE)
> instead of a provisional, the proxy has no way of
> >>>knowing a dialog was ever formed.
> >>
> >>I am not sure forming a dialog that way is allowed.
> >>
> >I'm pretty sure UACs end up needing to support this 
> >case; think dropped 1xx (unreliable, no sdp) or reordering in 
> >the network. In fact, even if our network is not reordering 
> >packets, sending a 1xx followed by an UPDATE will often have 
> >the UPDATE arriving first, since the 1xx has to traverse the 
> >full chain of proxies, whereas the UPDATE need only traverse 
> >the proxies that Record-Routed. It is possible that the proxy 
> >will never see a 1xx at all, but it is a bit of a stretch. 
> >Again, we're no worse off than we are now.
> 
> I still don't believe it's allowed to send UPDATE at that 
> point, because
> the UAS does not know (as you also mention) whether the unreliable 1xx
> will reach the UAC or not.
> 
> But, that discussion should probably be moved to a separate thread,
> because it's more core SIP than 199 specific.
[JRE] I think I can kill the discussion now, because you can only send
UPDATE on an early dialog if a reliable provisional response has been
used.

> 
> >>>It seems like this is something that works a whole lot 
> better if the
> >>>UAS is responsible for sending the 199.
> >>
> >>We can discuss that, but I think it's a little strange that a UAS 
> >>should send two responses (199 + final) when it wants to reject an 
> >>INVITE.
> > 
> >And I find it even stranger for a proxy to be 
> >manufacturing in- dialog responses. I understand the 
> >temptation to push this functionality into proxies; it makes 
> >upgrading a network much simpler. However, this is about 
> >Dialog signaling (end-to-end), and it really belongs in the 
> >endpoints.
> 
> Well, in that case, why are the 456xxxs terminated by the 
> forking proxy
> (which then sends one response towards the UAC)? Why not forward all
> responses all the way back to the UAC?
> 
> >It works much better that way. I suppose I can see allowing 
> proxies to
> do this sort of thing if they want, but I 
> >think any normative requirements should apply to endpoints.
> 
> We sure can discuss that alternative :) The main intention behind the
> draft is to make the UAC aware of terminated dialogs, so...
[JRE] I quite like the idea of the UAS sending the 199.

John

> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> > >
> > > Regards,
> > >
> > > Christer
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >>> Christer,
> > >>>
> > >>> Apologies if this has been discussed already, but isn't it
> > >> possible to
> > >>> have multiple 199s on a single early dialog? I am 
> considering the 
> > >>> following statement:
> > >>>
> > >>> "When a forking proxy receives a non-2xx final response which 
> > >>> terminates one or more early dialogs and the proxy does not
> > >> intend to
> > >>> forward the final response immediately (due to the rules
> > >> for a forking
> > >>> proxy) it MUST send a 199 provisional response, for each 
> > associated 
> > >>> early dialog that it can associate with the final response,
> > >> upstream
> > >>> towards the sender of the associated request."
> > >>>
> > >>> Suppose the request passes through proxy A, which forks and
> > >> sends one
> > >>> branch to proxy B, which also forks. One of the
> > >> destinations forked to
> > >>> by proxy B sends a 1xx (creating an early dialog) followed
> > >> by a 4xx,
> > >>> and proxy B, being unable to pass on the 4xx immediately,
> > >> sends a 199,
> > >>> which finds its way back via proxy A to the UAC. Later
> > >> proxy B sends a
> > >>> 4xx, and proxy A, being unable to pass on the 4xx
> > >> immediately, sends a
> > >>> 199. I guess if proxy A has released resources for that
> > >> dialog when it
> > >>> passed on the first 199, then the second 199 should not
> > >> arise. But the
> > >>> requirement to release resources is only a MAY.
> > >>>
> > >>> This seems undesirable, although harmless other than wasting 
> > >>> resources.
> > >>> Should we place a requirement on proxy A to prevent it?
> > >>>
> > >>> John
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Christer Holmberg (JO/LMF)
> > >>>> [mailto:[email-masked]]
> > >>>> Sent: 20 June 2007 19:45
> > >>>> To: sipping
> > >>>> Subject: [Sipping] draft-holmberg-sipping-199-02
> > >>>>
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> I've submitted a new version of the 199 draft, based on
> > >> comments I've
> > >>>> received.
> > >>>>
> > >>>> You can get it at:
> > >>>>
> > >>>> http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-
> > >>>> 199-02.txt
> > >>>>
> > >>>> I've added some text related to the dialog state 
> maintenance of 
> > >>>> proxies, and the open issues we've identified (e.g. 
> > related to the 
> > >>>> use with 100rel). I also added some 18x messages to 
> the example 
> > >>>> flows.
> > >>>>
> > >>>> 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
> > >>>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> 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
> > >>
> > >>
> > 
> > 
> 

_______________________________________________
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: [email-masked]
Date: Mon, 2 Jul 2007 11:48:47 -0400

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

   The main purpose of 199 is to allow the UAC to release resources.

There is trouble with the requirements of this I-D.  For instance, the
above statement is not a requirement in the I-D.  Conversely, the one
requirement in the I-D states that the *proxy* must generate the 199.
So we've specified one aspect of the solution (one which has been
debated here), but not specified the ultimate purpose of the
mechanism.

In regard to who generates the 199, it strikes me that a lot of the
difficulties and incongruences of this mechanism are eliminated if the
UAS generates 199 along with its final response.  E.g., there are no
issues of whether we're adhering to the overall transaction rules, and
there are no difficulties in re PRACK.

In regard to the "main purpose", as far as I can tell, the most common
situation where a UAC wants to release resources is releasing media
processing resources allocated to an early dialog media stream.  (A
UAC is likely to use only one NAT binding for one INVITE.)  However,
the mechanism defined here is insufficient to allow a UAC to do that
if it has not received an SDP answer from the UAS (and the UAC can
receive media on an early dialog before receiving an SDP answer for
that early dialog).

So I think we need to make sure that we have stated the requirements
that we really care about, and then make sure the mechanism suffices.

Dale

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 2 Jul 2007 23:58:26 +0200

Hi,

I guess it would be possible to change the wording of the requirement, so it talks more the UAC being informed about the terminated dialog instead of who is actually informing. Then, when/if we start discussing the actual mechanism, we'll see whether the forking proxy and/or the UAS sends the 199.

I guess we should also say that the main purpose is to inform the UAC about the terminated dialog as soon as it happens. The UAC MAY then (as the draft also says) use the indication to release different type of resources etc.

Regards,

Christer

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 2. heinäkuuta 2007 18:49
> To: [email-masked]
> Subject: Re: [Sipping] draft-holmberg-sipping-199-02
> 
> There is trouble with the requirements of this I-D.  For 
> instance, the above statement is not a requirement in the 
> I-D.  Conversely, the one requirement in the I-D states that 
> the *proxy* must generate the 199.
> So we've specified one aspect of the solution (one which has 
> been debated here), but not specified the ultimate purpose of 
> the mechanism.
> 
> In regard to who generates the 199, it strikes me that a lot 
> of the difficulties and incongruences of this mechanism are 
> eliminated if the UAS generates 199 along with its final 
> response.  E.g., there are no issues of whether we're 
> adhering to the overall transaction rules, and there are no 
> difficulties in re PRACK.
> 
> In regard to the "main purpose", as far as I can tell, the 
> most common situation where a UAC wants to release resources 
> is releasing media processing resources allocated to an early 
> dialog media stream.  (A UAC is likely to use only one NAT 
> binding for one INVITE.)  However, the mechanism defined here 
> is insufficient to allow a UAC to do that if it has not 
> received an SDP answer from the UAS (and the UAC can receive 
> media on an early dialog before receiving an SDP answer for 
> that early dialog).
> 
> So I think we need to make sure that we have stated the 
> requirements that we really care about, and then make sure 
> the mechanism suffices.
> 
> Dale
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: [email-masked]
Date: Mon, 2 Jul 2007 18:32:37 -0400

I guess it would be possible to change the wording of the
   requirement, so it talks more the UAC being informed about the
   terminated dialog instead of who is actually informing. Then,
   when/if we start discussing the actual mechanism, we'll see whether
   the forking proxy and/or the UAS sends the 199.

It would be reasonable to specify in the requirements that the proxy
sends the 199 if there was some justification from the real world that
it was important for the *proxy* to do so.  But I have seen no
argument that that is so.

   I guess we should also say that the main purpose is to inform the
   UAC about the terminated dialog as soon as it happens. The UAC MAY
   then (as the draft also says) use the indication to release
   different type of resources etc.

I still can't see why a UAC would care, or even be able to take any
useful action, based on a 199 *unless* the UAC could release media
processing facilities, and the requirements don't specify that the
mechanism must ensure that a UAC can release media processing
facilities, nor does the proposed mechanism allow a UAC to do so
reliably.

Let us not discuss "release resources" in the abstract, let us
describe some resources that could be released in practice that would
make a significant difference.  (That is, there is no real value in
the UAC releasing the few hundred bytes needed to keep track of the
mere *existence* of an early dialog.)

To be more blunt, I suspect that there exists a network design which
199 is designed to be part of, and within which it is useful, but the
design is not the standard type of SIP network, and more importantly,
this I-D is being careful to *not* reveal what that network design is.

But I have yet to see how 199 is particularly useful within any SIP
network I've ever heard of.  Until we have discussed an example in
which 199 would bring real benefit, why should we consider
standardizing it?  Indeed, why would anyone bother implementing it?

Dale

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 3 Jul 2007 07:51:40 +0200

Hi Dale,

Earlier I already gave examples of what type of "resources" could be released, and at that point you said you were "convinced" :)

Regards,

Christer 

> Sent: 3. heinäkuuta 2007 1:33
> To: [email-masked]
> It would be reasonable to specify in the requirements that 
> the proxy sends the 199 if there was some justification from 
> the real world that it was important for the *proxy* to do 
> so.  But I have seen no argument that that is so.
> 
> I still can't see why a UAC would care, or even be able to 
> take any useful action, based on a 199 *unless* the UAC could 
> release media processing facilities, and the requirements 
> don't specify that the mechanism must ensure that a UAC can 
> release media processing facilities, nor does the proposed 
> mechanism allow a UAC to do so reliably.
> 
> Let us not discuss "release resources" in the abstract, let 
> us describe some resources that could be released in practice 
> that would make a significant difference.  (That is, there is 
> no real value in the UAC releasing the few hundred bytes 
> needed to keep track of the mere *existence* of an early dialog.)
> 
> 199 is designed to be part of, and within which it is useful, 
> but the design is not the standard type of SIP network, and 
> more importantly, this I-D is being careful to *not* reveal 
> what that network design is.
> 
> But I have yet to see how 199 is particularly useful within 
> any SIP network I've ever heard of.  Until we have discussed 
> an example in which 199 would bring real benefit, why should 
> we consider standardizing it?  Indeed, why would anyone 
> bother implementing it?
> 
> Dale
> 
>

---

From: [email-masked]
Date: Fri, 20 Jul 2007 07:41:14 -0400

Earlier I already gave examples of what type of "resources" could
   be released, and at that point you said you were "convinced" :)

Yes, you're right.  Here's a copy of that message:
http://article.gmane.org/gmane.ietf.sipping/12325
and your explanation:
http://article.gmane.org/gmane.ietf.sipping/12309

Given that many people have this same concern, could you copy those
examples into the I-D so it's clear what "resources" we're concerned
about?

But I do still think that you've got a product that you're trying to
get us to bless -- there's only one requirement listed in the I-D,
that 199 be generated by the proxy, and that is a point that there is
no consensus on.  There's no point in giving that as a *requirement*,
unless there is an existing proxy that does that.

Dale

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 20 Jul 2007 19:38:01 +0200

Hi Dale,

>Given that many people have this same concern, could you copy 
>those examples into the I-D so it's clear what "resources" 
>we're concerned about?

Well, I thought I had done that, but I guess I can still improve it.

When presenting the draft next week, I will try to be more clear, and
give more precise examples.

>But I do still think that you've got a product that you're 
>trying to get us to bless -- there's only one requirement 
>listed in the I-D, that 199 be generated by the proxy, and 
>that is a point that there is no consensus on.  There's no 
>point in giving that as a *requirement*, unless there is an 
>existing proxy that does that.

It is true that the requirement in the document still talks about the
proxy. But, as we have discussed, another possibility is that the UAS
generates the 199, and I have said that the requirement should simply
said that "the UAC shall be informed" - without any wording about WHO
informs (that we would then discuss and decide upon in SIP, when we
discuss about the technical details). 

Unfortunately I haven't been able to update the I-D with the new
requirement wording, but when presenting the draft in Chicago I will
make it very clear that we are NOT at this point making a decission of
WHO is actually terminating the dialog. We are not even making a
decission about whether 199 will be used for it - we are simply going to
decide whether this is something we should work on.

And, no, I do NOT have a product that does this :)

Regards,

Christer