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

[Jonathan Rosenberg <[e-mail]>]

 

> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: Monday, September 10, 2001 7:11 AM
> To: Tan Ya-Ching ICM N MC MI E73
> Cc: 'Jonathan Rosenberg'; '[e-mail]'
> Subject: Re: [Sip] RE: Open Issue #138: to fork, or not to fork
> 
> >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.
> 
> 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. 

Egads! Please don't do things like that.

The lifetime of an early call leg is bounded by the lifetime of the invite
transaction. If an invite transaction ends in a non-2xx, all early call legs
with different tags have been terminated. If an invite transaction ends in a
2xx, existing early call legs have either been terminated, or a 2xx will
arrive within short order (assuming forking proxies cancel after 2xx, which
I have proposed is at least a SHOULD, if not a MUST; otherwise, the uac has
to cancel after the first 2xx to stop other branches). Thus, a short timer,
like 16s, will suffice. After that, any non-2xx'd early call legs are done.

This is worth adding to bis to describe.


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

More precisely, yes.
>  
> > 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 ?

I disagree with it, since it is a fundamental change to the proxy
transaction model. It will break backwards compatibility. That is really not
needed, since the problems it is trying to address can be solved as
discussed above in a backwards compatible way. 

Here is the bit Ya-Ching is talking about:

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


-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
http://www.dynamicsoft.com

_______________________________________________
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