Subject: RE: [Sip] RE: Open Issue #138: to fork, or not to fork

From: Tan Ya-Ching ICM N MC MI E73 <[email-masked]>
Date: Mon, 10 Sep 2001 11:51:34 +0200

I too am not going to propose the removal of forking, but I have some
questions regarding forking which I think should be resolved in the bis
draft.

I posted the following mail almost a month ago and have not received any
response. So here I reformulate the questions :

1) If a forking proxy can silently discard 4xx/5xx responses to
   early call legs because there were 2xx, 3xx or 6xx responses,
   how would the UAC know if an early call leg is still alive? There
   may be resources reserved for the early call leg and the UAC
   does not know if a 2xx response is still to come.

2) So a UAC can be unaware that an early call leg has been
    terminated by the UAS as the 4xx/5xx was 'swallowed' by
    the forking proxy. What happens if the UAC tries the terminate
    such an early call leg with a BYE (with a To tag), or if the UAC
    tries to send requests such as PRACK or INFO (with To tag)
    on such an early call leg? Would the proxy respond with 481
    (Transaction Does Not Exist) ?

3) The last paragraph of the following mail proposed a re-wording of
    the forking section of bis-04. What is your opinion on this
    proposal ?

- Ya-Ching

| -----Original Message-----
| From: Tan Ya-Ching ICM N MC MI E73 
| Sent: 14 August 2001 18:38
| To: [email-masked]'
| Cc: 'Jonathan Rosenberg'; 'Henning G. Schulzrinne'; Del Castillo
| Giuseppe ICM N MC MI E71
| Subject: [SIP] Forking proxy and early call leg (also : Early media draft)
| 
| 
| Figure 3 and Figure 5 of draft-rosenberg-sip-early-media-00 do not show
the
| correct handling of the 489 response (10) by the forking proxy. Figure 3
| shows that the 489 response is forwarded immediately upstream by the
forking
| proxy. According to the bis draft, for 4xx/5xx response received by the
| forking proxy, "the proxy MUST send an ACK. It remembers the response if
it
| has a lower status code class than any previous 4xx and 5xx response. On
| completion, a response with the lowerst response class is returned if
there
| were no 2xx, 3xx or 6xx responses". A SIP bis-compliant forking proxy
would
| therefore silently discard this 489 response, and forward only the 200 OK
| (19) upstream to the UAC.
| 
| This brings us to a question concerning "early call leg". J. Rosenberg
| proposed in an earlier SIP mail that "a 1xx with tags and record-routes
| establish an early call leg. Within that early call leg, you can send
| non-INVITE requests, including PRACK, INFO, BYE, etc., as you would for an
| answered call leg". But how would the client be aware that the forking
proxy
| has received a non-2xx final response and as a result, that particular
early
| call leg has been terminated ?
| 
| We therefore propose the following slight modification of forking proxy
| behavior to section 17.4 (Forking Proxy) of the bis draft :
| 
| Once the forking proxy has received and forwarded a provisional response
| with a To tag upstream, it MUST forward upstream any final non-2xx
responses
| received on that branch, regardless of the responses received on the other
| branches. On branches where no provisional responses with To tag were
| received, the forking proxy behaves as usual, by selecting the "best
| available final status" for those branches.
| 
| 
| - Ya-Ching Tan & Giuseppe Del Castillo
| 
| 

| 

_______________________________________________
Sip mailing list  http://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 <[email-masked]>
Date: Mon, 10 Sep 2001 14:11:16 +0300

Hi,

>   does not know if a 2xx response is still to come.

This is a good question. I mentioned before, when we discussed the
CANCEL/BYE of specific legs, that the UAC may not want to accept the
first final response - not even if it is 200 OK. Instead, the UAC may
make the decission which final response it will accept based on some
information in the provisional responses. But, as you said, if the final
response then never arrives no call will be established, and resources
will remain reserved (until the UAC realises that there will be no final
response).

Of course, it COULD be an extension feature (defined as a Proxy-Require
option-tag) to make sure that ALL final responses are sent back to the
UAC. 
 
>    (Transaction Does Not Exist) ?

Probably. That, however, would probably not be a very big problem on a
functional level, since the UAC is going to forget about the leg in any
case - no matter what response code it receives.

Regards,

Christer Holmberg
Ericsson Finland