[reSIProcate] Getting unexpected debug errors

[Alan Hawrylyshen]

On 2005.12.13, at 01:07 , John Draper wrote:

> Hi,
>
> After getting about 5 or 6 "100 trying" messages in the logs,  I  
> got two "180 Ringing"
> messages....   See below.

Honestly John;
You claim that you read RFC 3261, so I propose that you are just  
trying to irritate us.
 From Section 8.1.1 Generating the Request
...
CSeq : The CSeq header field serves as a way to identify and order  
transactions. It consists of a sequence
number and a method. The method MUST match that of the request. For  
non-REGISTER requests outside
of a dialog, the sequence number value is arbitrary. The sequence  
number value MUST be expressible as a
32-bit unsigned integer and MUST be less than 2**31. As long as it  
follows the above guidelines, a client
may use any mechanism it would like to select CSeq header field values.
Section 12.2.1 discusses construction of the CSeq for requests within  
a dialog.
	Example:
		CSeq: 4711 INVITE


Section 12.2.1.1 (Emphasis mine) Generating the Request


    *Requests* within a dialog MUST contain strictly monotonically
    increasing and contiguous CSeq sequence numbers (increasing-by-one)
    in each direction (excepting ACK and CANCEL of course, whose numbers
    equal the requests being acknowledged or cancelled).  Therefore, if
    the local sequence number is not empty, the value of the local
    sequence number MUST be incremented by one, and this value MUST be
    placed into the CSeq header field.  If the local sequence number is
    empty, an initial value MUST be chosen using the guidelines of
    Section 8.1.1.5.  The method field in the CSeq header field value
    MUST match the method of the request.

CSeqs in responses match the Request.


Secondly,
maddr is NOT how you route requests. The To line is of little  
consequence to the stack. Only proxies (and UAs) care about the To  
line URI. Certainly the stack does not. If you want broken SIP that  
goes somewhere other than where the protocol says it will go, then  
you want to call sendTo(...Tuple...) not send().
If you cannot make DNS do the right thing, you are going to have lots  
of problems.