Re: [Sip] Moving forward on non-invite issues

[Jonathan Rosenberg <[e-mail]>]

Its late, I'm tired, so there is a good chance that what I am saying 
below makes no sense.

It occurs to me that there is another solution (and I dont recall if we 
discussed it), which can alleviate many of the problems in the problems 
draft. The idea is that we define two separate NIT timeouts - one for a 
client or proxy, and one for a server that generates its own responses 
(as opposed to forwarding ones generated by others). The server one is 
1/2 the size of the client one. We could, for example, keep the client 
one at 32 and make the server one 16.

In this case, a UAS would HAVE to send a 408 if it cant complete the 
transaction in 16s. However, this 408 will not arrive too late at any 
upstream elements, since all of them have still 16s remaining.

AFAICT, this approach has the following impacts on the problems in your 
problems draft:

1.1 is solved. You reply immediately, if not, a UAS has to reply within 
16s with a 408. The race then becomes possibly if it takes 16 for the 
response to propagate - if thats a problem, then the noninvite 
transaction duration itself is too small for that network.

1.2 is not solved. I see this is quite separate from the other problems. 
TCP does solve it tho.

1.3 is solved. You should get a response now before the transaction 
completes.

1.4 is solved. 408 is still useful. Its always sent by the uas before 
the upstream transactions terminate.

1.5 is sort of solved, but not completely. If an element has failed, 
you'll not get a 408 at all, so the proxy still waits too long to get a 
response from the failed element. Need to think about that some more.

1.6 is still a problem; thats fundamentally unsolvable without some kind 
of negotiation or mandatory minimum.


This is, to some degree, a vairation on the Timeleft approach in your 
futures draft.

-Jonathan R.





Robert Sparks wrote:

> All -
> 
> At the request of the chairs, I split the non-invite
> draft into three parts :
> 
> - the description of the problems
> - the things we seem to have consensus to fix now
> - the things we might do in the future but need to
>   argue over more.
> 
> 
> The resulting drafts are available in the repository:
> http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-problems-00.txt
> http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-actions-00.txt
> http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-future-00.txt
> 
> 
> My recommendation is to LC the problems and actions drafts
> as soon as it is feasible to do so and send them to the IESG.
> 
> RjS
> 
> ps - if you prefer reading xml2rfc's html output, you
> can get that at:
> http://www.nostrum.com/~rjsparks/draft-sparks-sip-nit-problems-00.html
> http://www.nostrum.com/~rjsparks/draft-sparks-sip-nit-actions-00.html
> http://www.nostrum.com/~rjsparks/draft-sparks-sip-nit-future-00.html
> 
> 
> _______________________________________________
> Sip mailing list  https://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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://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