[reSIProcate] Getting unexpected debug errors

[John Draper]

Alan Hawrylyshen wrote:

>
> 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

Look - there are 275+ pages in just one of 3 or 4 RFC specification 
documents.  I HAVE
read it,  but I cannot possibly remember every word I've read.  I know 
I'm a slow learner,
but I don't believe I'm out of line asking this.  I see others asking 
questions that appear
to be as being obvious, but I'm expecting others are also having more 
then usual problems
because of the lack of examples and docs, and I know I'm not the only 
one saying this.
If I "appear" to be irritating the list,  I apologize for it.  Like 
everyone new that comes
on this list, people are going to ask questions.

> ...
> 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().

Obviously I did not know this.  Is this used in any of the test code?   
I didn't see any mechanism
of sending used in "test" other then "send".  So,  no - I did NOT know 
about this,  but now that
it was brought to my attention,  I'll certainly look into it.  I don't 
suppose anyone might have
some examples how to use it?

> If you cannot make DNS do the right thing, you are going to have lots  
> of problems.

If I can control the DNS from the client side and not the server side,  
I would have
no problems.  I don't have control over what I can do on the Server 
side.  Nor can I
make any policy decisions in that regard.

Just to let you know,  I AM figuring things out, and I AM making 
progress,  just not
as fast as I'm used to when dealing with other libraries or modules.

John