Subject: [Sip] Let's discuss a change in the bis. WAS: Why Proxies are Good and B2BUAs May Not Be

From: [email-masked]
Date: Thu, 28 Feb 2002 10:17:33 +0100

Hello Dean,
 thanks for your comments. I'd like to add some more thoughts.

Dean says:
> As the SIP specification does
> specify the transfer encoding at layer 3, so it's an open 
> question whether a different encoding would still be 
> "standard". But one could theoretically
> preserve feature transparency over such a coding, so a 
> "proxy" in this mode is not completely ridiculous.

Right. I would like to add just a general idea. ;)
In my view it may have been sensible that time to include 
an encapsulation in the SIP RFC, but in the long run it 
does more hinder further evolution of SIP in an ever 
changing protocol world. 
A longlasting successful protocol should be able to 
interchange mappings (or encodings, encapsulations) 
of it's respective lower layers if need arises. 
SIP-architects could have looked at the way PPP was 
designed for example, e.g. the layering. (Not a perfect 
example of course, but it gives hints ;)

SO, as it already has been defined as it is, I would 
like to formaly suggest a change in the RFC-bis ;)

Let's put it that way, that the encoding of the SIP 
verbs and the needed 'header fields' can be changed, 
as long as all values are transmitted in their proper 
sequence without alteration by a lower layer. Also,
the lower layer protocols must be capable of transporting 
MIME-compliant payloads with the SIP messages.
One example of an alternative encapsulation would then 
be an XML-encoding transmitted over standard HTTP.
Others are possible.

..
Phew, a bold step :;)

> > > Essentially, anything that does SIP->somethingelse->SIP can
> > > be considered a
> > > form of B2BUA.
> > No. Only *if* it changes the data.
> 
> Or if it changes the timing characteristics, etc.

You are right, but are timing characteristics defined 
sufficiently complete in the RFC at all? What has been 
defined, at least what I know, is not protocol-dependant. 
Do you agree? 
[The only timing component relating to the transport 
layer is the usage of UDP instead of TCP, but that is
an implicit feature of UDP, and TCP is at least allowed 
as well.]
As a sidenote, has the proposed usage of the Stream Control
Protocol (i do hope I spelled it right ;) ever been checked 
against this? At least not that I've read about...

> > >Feature transparency across such a stucture
> > > requires a fully
> > > homomorphic mapping between SIP and somethingelse.
> > It does not map SIP to something else,
> > it only encapsulates the SIP header fields into XML-tags.
> 
> So what does it do if it sees a SIP message type that it's never seen
> before?

The SIP messages must be encapsulated in a way that 
does not define values of higher layers in a lower one.

SO, you would NOT use code like this:
---
<?xml version='1.0' ?>
<sip version="2.0">
 <invite>
 </invite>
</sip>
---

but rather like this:

---
<?xml version='1.0' ?>
<sip version="2.0">
 <request verb="INVITE">
 </request>
</sip>
---

> 
> . . . .
> The semantics of SIP, in general, are a bit strained 
> by the REGISTER process. 
That's the fate of an all-purpose-protocol ;)
In a way any, SIP-semantics are also non-orthogonal 
since user-data can be sent in-band ;) 

...
> Actually, there is a SIP Servlet specification.
Oh, where can I find that? 
[And, may I add, where is a Servlet-Container supporting 
it? As far as I've found up to now, there is not a single 
application server of servlet container around that really
supports Non-HTTP servlets. ]

Best greetings, 

Thomas Nagel

_______________________________________________
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