Subject: Re: [Sip] Provisional response to terminate early dialog

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 01 Feb 2005 00:12:02 -0500

Robert Sparks wrote:

> How is this bound to 64T1?
> 
> It's an INVITE transaction - it can pend potentially indefinitely 
> (though timer C will likely kick in to muck up the works).

Oops, you are right. My brain is still not up to speed due to the nasty 
cold I suffered through this weekend.

> 
> I can see the kind of cases Christer is considering:
> 
>   1) You parallel fork to several places. All initiate early media. All 
> but one
>        return an error code that doesn't stimulate immediate forwarding 
> in the
>        proxy response context (say, 401just to see the situation, as odd 
> as that
>        would be to mix w/ early media). One leg just stays pending. The 
> initiating
>        UA will hold onto the resources for early media for _all_ of 
> those legs until
>        the pending leg completes.
> 
> 2) If you have a serial forking proxy, and each leg initiates early 
> media, at the
>     end of the fork, the initiating UA is holding early media resources 
> for each
>     previous leg - it has no way to let go before it gets a final response.
> 
> Personally, I see this as just one of the consequences of the
> terrible thing we did when we allowed early media in the first place.
> I am reticent to further complicate the protocol by introducing 
> provisionals
> along the lines Christer is proposing - that step takes us most, if not 
> all, of the way to having
> transactions within transactions. Taken to an extreme, this could solve 
> HERFP
> by tunneling all the final responses on the other side of a proxy back 
> to the UA
> so it might be able to do something about it (say they were 421 Extension
> Required responses: A UA could deal with those immediately by initiating a
> new branch, parallel forking at the UA (yuck)). This could even lead to 
> pressure
> to change the merging rules so that a UA can deal with 401s as part of 
> early dialogs
> by reissuing the request on a new branch (double-yuck).

Well, you may recall that the initial proposed solution to HERFP was to 
use a provisional response instead of a final one for errors that are 
fixable. As such, I would argue that the problem Christer is worried 
about *is* the HERFP problem, and if we want to solve anything, we 
should solve that more generic one rather than this specific 
instantiation of it.

Now, do we want to really solve the HERFP problem? Initially I thought 
we would for sure, but reality and actual usage has yet to show this as 
a pressing problem...

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.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: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 1 Feb 2005 08:07:17 +0100

Hi,

In my use-case I actually meant to say SERIAL forking, not parallel. Of course, from a UAC perspective it doesn't matter (it doesn't know how the forking is done).

However, the fact that we can receive early media from multiple UASs in the parallel case I probably something we can do very little about, and if many nodes send early media at the same time it may not help much to have an indication on when a dialog is terminated.

In the serial case, however, there will only be early media from one node at a time. But, when one fork is terminated, the media may "switch" to another dialog, initiated by the next fork. But, again, since the UAC doesn't knows that there will be no more early media from the first fork it may keep the resources reserved for the first fork until it receives a final response from another fork.

Jonathan said in his second reply that we need to find out if this will be a problem in reality.

The reason for my initial question was basically due to the work on supplementary services which is currently ongoing in the ETSI TISPAN and 3GPP bodies. Some services will provide early media/announcments, and one idea is that they will be associated to a specific early dialog. The media coming from the actual UAS will then be associated with another dialog. To describe it easy, from a SIP perspective there would be a proxy doing serial forking, first to the announcement UAS, and then to the actual UAS.

The problem is that a 3GPP UAC may choose not to accept (for a number of technical reasons) multiple early dialogs, so in this case it would probably accept the first "announcement" dialog, but not the UAC-UAS dialog - which is of course bad. However, if the node doing the forking would be able to directly, when the announcement has finished, indicate to the UAC that the announcement dialog is terminated, the UAC could free the resources associated with that and then accept the UAC-UAS dialog.

So, I think that would be a very good feature, and I don't think it would take much to define it. And, using a provisional response would (as I said earlier) also be backward compatible.

Now, about forwarding mutliple FINAL responses - I don't think we should go that way - at least not until we have real requirements for it. It would require much more work - not only to forward the responses themselves, but also to handle the possible actions that may/should/should not be taken by the UAC when receiving multiple final responses. There would probably also be backward compability issues.

As Jonathan said, one thing could be to include the final response code in the new provisional response. The UAC could then, depedning on the response code, its implementation logic etc, choose to CANCEL the WHOLE INVITE, and re-issue a new INVITE (for example including extensions which were required). I do NOT think that we should go the transaction-within-transactions way, and start sending "new INVITEs" for certain early dialogs.

Regards,

Christer Holmberg
Ericsson Finland

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: 31. tammikuuta 2005 19:31
> To: Jonathan Rosenberg
> Cc: [email-masked]'; Christer Holmberg (JO/LMF)
> Subject: Re: [Sip] Provisional response to terminate early dialog
> 
> 
>         proxy response context (say, 401just to see the situation, as 
> odd as that
> In shorter words, I think this is a problem we should admit we have, 
> but not
> try to do anything about. If we _do_ choose to do something about it, 
> then we
> better carefully bound the scope.
> 
> RjS
> 
> On Jan 30, 2005, at 8:39 AM, Jonathan Rosenberg wrote:
> 
> >
> >
> > Christer Holmberg (JO/LMF) wrote:
> >
> >> Hi,
> >> Today, when a request gets forked, the forking proxy will 
> "collect" 
> >> final responses received from the different dialogs.
> >> The calling UAC, however, does now know when specific 
> early dialogs 
> >> are
> >> terminated, since the forking proxy will not forward the 
> final answer.
> >> That means that the UAC may have to keep resources etc that it 
> >> reserved when the early dialog was created (by a 18x provisional 
> >> response)
> >> available until the proxy forwards a final response.
> >
> > This is a relatively small amount of time - 32 seconds.
> >
> >> Would it somehow be possible to define a "dialog has been 
> terminated" 
> >> response code that the proxy could
> >> send to the UAC directly each time it receives an error 
> response from 
> >> any of the forked dialogs. A provisional response code 
> would probably 
> >> be good, because it would be backward compatible (nodes that don't 
> >> support it simply keeps the early dialog alive until the final 
> >> response comes from the forking proxy, as today).
> >
> > I don't really see what the problem is. Is this 32 seconds 
> or so that 
> > critical? Besides shaving a few seconds off the amount of 
> time that a 
> > UAC holds transaction state, is there any other benefit?
> >
> > -Jonathan R.
> >
> > --