Re: [reSIProcate] RFC Question...

[Alan Hawrylyshen <alan@xxxxxxxxxx>]

Inline.
On Jul 22, 2005, at 14.10, John Draper wrote:

> kaiduan xie wrote:

> >
> So - you say a SUBSCRIBE would be a request within a dialog?

A SUBSCRIBE is a request that creates a dialog.


> I just got to this section last night.  But I'm still trying  
> understand it.
> For instance "Within this specification, only 2xx and 101-199  
> responses with
> a To tag...."  was it implying that responses will have a "To" tag  
> in it?

Consider only requests that can create dialogs (eg. INVITE,  
SUBSCRIBE, tbd..)

It is saying that ALL 2XX responses create a dialog  AND all 101-199  
responses with a to-tag create a dialog.
(Potentially you will get responses that meet BOTH these criteria as  
you process request responses, in that case it is the earlier of the  
two that create the single dialog).

> > The components of the state means: dialog ID, a local
> > sequence number, a remote sequence number, a local
> > URI, a remote URI, remote target, ...
> Oh,  so a Component is like a "header field" or related to them.   
> Right?

State is conveyed or derived from header fields.  Recall that a  
protocol is just a semantic and syntactic way of exchanging state  
(information) in a well-specified manner. Ultimately SIP is a  
protocol for exchanging offers and answers, effectively exchanging  
state between two end points. This state is specific to the realm of  
location of services and establishing sessions.


> I had trouble associating a "Piece of state" with a header field.
> But interpreting what you said,  this is what I understand.


SIP is not a bunch of bits on a wire. It's a framework for  
applications. (Sometimes thought of as a layer-7 protocol). In some  
ways, you can argue that SIP is not quite layer 7 in the ISO protocol  
model, since things like event packages, and their application  
(presence, IM, voice, video, C3I, chess, horseshoes, battleship) are  
the real application and SIP acts more like the "session" layer,  
however the mapping from the IP world to the old-school ISO layer  
cake is not solid.

See http://www.networkdictionary.com/protocols/iso.php for more on  
ISO / OSI layers.

Given that context, SIP (all by itself) is really close to being a  
"Session" protocol (the coincidence potentially being just that) and  
not the true application layer.  The application layer (or  
functionality) is something that DUM provides (conceptually) on top  
os resiprocate.

I think that you will find it very difficult to effectively use  
resiprocate without DUM. DUM tries very hard to isolate the user from  
the arcane details of SIP, it's handful of RFCs (3261-3265, 2543bis9 
(deprecated), and MANY more).  DUN can let someone 'get the drift'  
and leverage SIP.  Using the stack under DUM will likely cause  
problems for someone not well-versed in SIP.

Some excellent reading on general networking:

    http://www.kokogiak.com/amazon/detpage.asp?sb=s&asin=0130661023