Subject: RE: [Sip] Updated gruu mechanism spec

From: "Chris Boulton" <[email-masked]>
Date: Mon, 8 Dec 2003 09:16:08 -0000

Christian,
	I agree BUT isn't this a more generalized recommendation for UA's using TCP.  Maybe this type of information would be better suited in a generic TCP usage doc.

Chris.

>-----Original Message-----
>From: Christian Stredicke [mailto:[email-masked]]
>Sent: 07 December 2003 15:13
>To: 'Jonathan Rosenberg'
>Cc: [email-masked]
>Subject: AW: [Sip] Updated gruu mechanism spec
>
>Hi Jonathan,
>
>I think we should add to the draft that the user agent which registers
>using gruu and TCP must not close its TCP connection at least until the
>registration expires (also the server must not close this connection,
>but I think that's clear). This would be an important clarification on
>the TCP stuff which has recently been discussed.
>
>If that desire should be programmable (to limit the number of concurrent
>TCP connections on the server), then we must include a hint for the user
>agent on how to behave. But surely the default behavior should be the
>above.
>
>Christian
>
>> -----Ursprüngliche Nachricht-----
>> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
>> Jonathan Rosenberg
>> Gesendet: Freitag, 5. Dezember 2003 23:21
>> An: [email-masked]
>> Betreff: [Sip] Updated gruu mechanism spec
>>
>> Folks,
>>
>> Based on discussions during the IETF 58 meeting, I've submitted a
>> revision to the gruu mechanism document. Until it appears in the
>> archives, you can pick up a copy at:
>>
>> http://www.jdrosen.net/papers/draft-rosenberg-sip-gruu-01.txt
>>
>> The changes are as follows:
>>
>> * clarified that the registrar needs to return the same gruu in
>> registration refreshes, and this requires reliable storage. No
>> requirement for returning the same gruu across registrations.
>>
>> * clarified that the registrar should ignore any gruu parameter
>> provided in the contact header fields of a registration
>>
>> * mention that, it is still possible that a gruu changes in a
>> registration, in the case where there is a race condition where the
>> client thinks its refreshing, but the registration has just expired at
>> the registrar. As such, recommend that a UA be prepared to deal with
>> such a change.
>>
>> * removed text about using this mechanism to replace dialog reuse
>>
>> * added some more details on the encryption mechanism, such as
>> recommended algorithm and key lengths. Also clearly state that this is
>> just one way to do it, you can do it statefully if you want.
>>
>> * proxies are prohibited from redirecting a request to a gruu, they
>> have to proxy it. If they redirect, you'll ruin any nat traversal
>> benefits associated with gruus.
>>
>> * clarified that gruus don't provide sufficient privacy services, and
>> added a reference to the privacy spec
>>
>> * removed the notion of locally generated gruus. The text now says you
>> need to use the registration mechanism in the draft to obtain a gruu.
>> The result is the end of e2e signaling. It also mentions that a new
>> specification is forthcoming which will address this limitation.
>>
>>
>> At this point, there are no known open issues. I would like to see if
>> there is consensus to adopt this item as a work item of the sip
>> working group. I do not believe we took such a poll during the
>> meeting. Chairs - can you assist?
>>
>> Thanks,
>> Jonathan R.
>>
>> --
>> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
>> Chief Technology Officer                    Parsippany, NJ 07054-2711
>> dynamicsoft
>> [email-masked]                     FAX:   (973) 952-5050
>> http://www.jdrosen.net                      PHONE: (973) 952-5000
>> 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 [email-masked] for questions on current sip
>> Use [email-masked] for new developments on the application of sip
>
>
>_______________________________________________
>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
>
>________________________________________________________________________
>This email has been scanned for all viruses by the MessageLabs Email
>Security System. For more information on a proactive email security
>service working around the clock, around the globe, visit
>http://www.messagelabs.com
>________________________________________________________________________

This message has been scanned for viruses by MailControl - www.mailcontrol.com

_______________________________________________
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: "Christian Stredicke" <[email-masked]>
Date: Mon, 8 Dec 2003 17:28:03 +0800

Hi Chris,

well usually it is a good idea for the UAC to close the TCP connection
in order to keep the load on the server low. But in the specific case of
obtaining a GRUU (behind NAT) this is not a good practice; therefore I
think it fits well into the GRUU draft.

Christian

> Von: Chris Boulton [mailto:[email-masked]]
> Gesendet: Montag, 8. Dezember 2003 17:16
> An: Christian Stredicke; Jonathan Rosenberg
> Cc: [email-masked]
> Betreff: RE: [Sip] Updated gruu mechanism spec
> 
> Christian,
> 	I agree BUT isn't this a more generalized recommendation for
UA's
> using TCP.  Maybe this type of information would be better suited in a
> generic TCP usage doc.
> 
> Chris.
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Dec 2003 00:45:23 -0500

> think it fits well into the GRUU draft.

Keeping the connection open to the server is a necessary practice for 
SIP to work through nat, independently of whether you are using gruus 
or not. As such, I agree with Chris that this kind of behavior belongs 
in the tcp bcp document that has been discussed on the list.

-Jonathan R.

---

From: "Christian Stredicke" <[email-masked]>
Date: Wed, 10 Dec 2003 05:41:15 +0800

Jonathan,

if you read carefully you will see that I am talking about the client.
The client usually closes the TCP connection after the transaction or a
short timeout. That is not ok with a REGISTER transaction when gruu and
NAT is involved.

CS

> Gesendet: Dienstag, 9. Dezember 2003 13:45
> An: Christian Stredicke
> Cc: 'Chris Boulton'; [email-masked]
> Betreff: Re: AW: [Sip] Updated gruu mechanism spec
> 
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Dec 2003 10:57:22 -0500

Yes, I knew you were talking about a client. Its also not OK for the 
client to close a connection with a REGISTER transaction when gruu 
isnt' used, if nat is involved. My point was that GRUU changes nothing 
beyond normal registrations, as far as this problem is concerned.

Thanks,
Jonathan R.

Christian Stredicke wrote:
>>>well usually it is a good idea for the UAC to close the TCP
> 
> connection
> 
>>>in order to keep the load on the server low. But in the specific
> 
> case of
> 
>>>obtaining a GRUU (behind NAT) this is not a good practice; therefore
> 
> I
>

---

From: "Christian Stredicke" <[email-masked]>
Date: Fri, 12 Dec 2003 04:03:08 +0100

Hmm. Ok I got the point (took a little time...). Let's put it into a
BCP!

Christian

> Von: Jonathan Rosenberg [mailto:[email-masked]]
> Gesendet: Donnerstag, 11. Dezember 2003 16:57
> An: Christian Stredicke
> Cc: [email-masked]
> Betreff: Re: AW: AW: [Sip] Updated gruu mechanism spec
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 30 Dec 2003 09:15:01 -0800

Agree this has nothing to do with GRUU ...

I don't think I agree that closing the TCP connections frequently (like
after every transaction) lowers the load on the server. My experiments
indicate it makes it worse. I have been recommending that phones, once they
open an TCP connection, leave it open as long as they can but be prepared
for the proxy to close it if the proxy runs out of resources.

Cullen