Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP

From: [email-masked]
Date: Fri, 3 Aug 2001 15:16:26 +0300

Hi,

I would still ask for some further clarification.

Jonahan Rosenberg wrote:
> 
> Yes, exactly. I am not proposing a new tranport protocol that 
> needs to be
> signaled within IP (peer to UDP, TCP), but rather something that SIP
> considers a transport protocol. This means that we can have 
> SRV records of
> the form:
> 
> _sip._cudp.foo.com
> 
> which would identify servers for foo.com providing SIP over 
> this transport
> (Compressed UDP, or whatever we call it). We can also have a SIP URL
> transport param:
> 
> sip:[email-masked];transport=cudp
> 
> which can be used in record-routing, for example.
> 

I think this looks like a good solution for negotiating whether there is
compression at all or not, especially if SIP is considered. I don't know how
e.g. HTTP would work, would there be a new port for "compressed HTTP" as (at
least originally) defined for SSL/TLS?  

Two additional points:

1) Would it be so that SIP over "CUDP" would use a different destination
port than SIP over UDP? Or how else does the receiver know whether the
incoming packet contains a compressed or an uncompressed SIP message? 

2) I don't know if there is need for more complex negotiation. If so, I
assume this would somehow take place within the compression layer. As the
solution should be application-protocol neutral, it is probably not a good
idea to use e.g. SIP headers for this. I guess the required negotiation
could be piggy-packed within the initial protocol transaction, which in SIP
would be REGISTER-200.

> -Jonathan R.
> 
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  http://www.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
> 

Markus

_______________________________________________
Sip mailing list  http://www.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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 3 Aug 2001 14:12:52 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 03, 2001 8:16 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP
> 
> 
> > _sip._cudp.foo.com
> > 

That is one way, but again - the http client has to have some way of
handling the case when the server doesn't support compression, and is
therefore not listening on this port. This is why, in http, the negotiation
of the transport (tls/tcp) is handled within the http spec. In general, I
see no way around negotiating the use of the compression on an application
protocol by protocol basis.

> incoming packet contains a compressed or an uncompressed SIP message? 

SRV allows for the server to indicate what port it is expecting a particular
transport on. So, we could standardize a port, but SRV would eliminate the
need for it.

> transaction, which in SIP

As I have said, I think it is unavoidable for each application protocol to
have to specify how to signal the usage of the compression in the first
place.

-Jonathan R.

---