Subject: [Sip] Provisional response to terminate early dialog

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sun, 30 Jan 2005 13:56:54 +0100

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.

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).

There may have been some work on this issue, or similar, before, but I can't remember the details.

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Sun, 30 Jan 2005 09:39:03 -0500

> available until the proxy forwards a final response.

This is a relatively small amount of time - 32 seconds.

> 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 t…

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.

-- 
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

---

From: Robert Sparks <[email-masked]>
Date: Mon, 31 Jan 2005 11:30:55 -0600

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).

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).

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:

>> Today, when a request gets forked, the forking proxy will "collect" 
>> final responses received from the different dialogs.
>> 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)
>> 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).
>