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

[Tan Ya-Ching ICM N MC MI E73 <[e-mail]>]

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: '[e-mail]'
| 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip