[Home]

Summary:ASTERISK-01773: Transaction Mismatching in Register
Reporter:nakata (nakata)Labels:
Date Opened:2004-06-07 06:13:21Date Closed:2008-01-15 14:57:59.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:RFC 3261
Page 137&ASTERISK-11712;138
17.2.3 Matching Requests to Server Transactions

  When a request is received from the network by the server, it has to
  be matched to an existing transaction.  This is accomplished in the
  following manner.

  The branch parameter in the topmost Via header field of the request
  is examined.  If it is present and begins with the magic cookie
  "z9hG4bK", the request was generated by a client transaction
  compliant to this specification.  Therefore, the branch parameter
  will be unique across all transactions sent by that client.  The
  request matches a transaction if:

     1. the branch parameter in the request is equal to the one in the
        top Via header field of the request that created the
        transaction, and

     2. the sent-by value in the top Via of the request is equal to the
        one in the request that created the transaction, and

     3. the method of the request matches the one that created the
        transaction, except for ACK, where the method of the request
        that created the transaction is INVITE.

  This matching rule applies to both INVITE and non-INVITE transactions
  alike.

     The sent-by value is used as part of the matching process because
     there could be accidental or malicious duplication of branch
     parameters from different clients.

  If the branch parameter in the top Via header field is not present,
  or does not contain the magic cookie, the following procedures are
  used.  These exist to handle backwards compatibility with RFC 2543
  compliant implementations.

  The INVITE request matches a transaction if the Request-URI, To tag,
  From tag, Call-ID, CSeq, and top Via header field match those of the
  INVITE request which created the transaction.  In this case, the
  INVITE is a retransmission of the original one that created the
  transaction.  The ACK request matches a transaction if the Request-
  URI, From tag, Call-ID, CSeq number (not the method), and top Via
  header field match those of the INVITE request which created the
  transaction, and the To tag of the ACK matches the To tag of the
  response sent by the server transaction.  Matching is done based on
  the matching rules defined for each of those header fields.
  Inclusion of the tag in the To header field in the ACK matching
  process helps disambiguate ACK for 2xx from ACK for other responses
  at a proxy, which may have forwarded both responses (This can occur
  in unusual conditions.  Specifically, when a proxy forked a request,
  and then crashes, the responses may be delivered to another proxy,
  which might end up forwarding multiple responses upstream).  An ACK
  request that matches an INVITE transaction matched by a previous ACK
  is considered a retransmission of that previous ACK.



It has written in RFC3261 clearly as mentioned above about matching of a transaction.
However, the transaction of Asterisk of the first Register and Register containing the attestation header after receiving an attestation demand corresponds at the time of Register. Only by the increase in Cseq, in RFC3261, although it is a different transaction, it does not become precocious. Consequently, Register containing an attestation header is judged to be resending of the first Register. This is violation of RFC.
Comments:By: Mark Spencer (markster) 2004-06-07 11:22:13

I'm not even remotely getting the picture here, so maybe an annotated example of what we're doing wrong would be helpful.
By: nakata (nakata) 2004-06-07 19:59:08

That there is two protocol in SIP knows.
They are RFC2543 and RFC3261.
When it became new from RFC2543 to RFC3261, the matching rule of a transaction changed.

Although Asterisk is based on the matching rule of the transaction of RFC2543, it is the talk of being against it of RFC3261.

I talk explaining a few. Please point out, if an error should be in my interpretation.

RFC2543 and RFC3261 are classified according to the existence of branch of a Via header.
When branch begins from the key "z9hGbK", it is distinguished that the UA is based on RFC3261.

In RFC3261, as it is in 17.2.3 of the point, when branch is the same value, the same transaction, i.e., UAS, mainly treats with resending.

Asterisk is the same branch as a request without the first attestation, when sending a request with attestation. In UAS based on RFC3261 by this, it is judged as resending of the first request, the attestation demand response to the first request is returned, and it does not succeed in attestation forever. These two requests are completely different transactions.
This is the fault common to INVITE of Asterisk, and REGISTER.

On the other hand, under the rule of RFC2543, it is judged as another transaction because Cseq differ. Asterisk is carrying out the increment of the Cseq.

Probably, branch must not be included if it is it an idea not to want to be unable to solve this or to solve it.
By: Mark Spencer (markster) 2004-06-07 21:26:37

Can you provide an example -- a sample SIP trace, annotated with what you think is incorrect about Asterisk's behavior, e.g. "See right here it says 'foo' but should say 'bar' instead"?
By: nakata (nakata) 2004-06-07 22:16:13

A call flow is explained to an example.
The first call flow is a normal case.
The second call flow is the case which the fault of Asterisk generates.

Call-Flow-1(Register)
                                                 
Something-UAC  . . . .  . . . Something-UAS                              
             REGISTER F1      
    |-------------------------->|
                               
         401 Unauthorized F2    
    |<------------------------- |
                               
             REGISTER F3      
    |-------------------------->|
                               
             200 OK F4        
    |<--------------------------|
                               


Call-Flow-2(Register)
                                                 
 Asterisk  . . . . . . . . . Something-UAS                              
             REGISTER F11      
    |-------------------------->|
                               
        401 Unauthorized F12  
    |<------------------------- |
                               
             REGISTER F13      
    |-------------------------->|
                               
        401 Unauthorized F14  
    |<--------------------------|
                               
             REGISTER F15      
    |-------------------------->|
                               
        401 Unauthorized F16  
    |<--------------------------|
                               
                 .
                 .
                 .


Call-Flow-1(Register)
<REGISTER F1>
Via: something@192.168.0.2:5060;branch=z9hG4bK123456789
Cseq: 1
.
.
.

<REGISTER F3>
Via: something@192.168.0.2:5060;branch=z9hG4bK987654321
Cseq: 2
.
.
.



Call-Flow-2(Register)
<REGISTER F11>
Via: asterisk@192.168.0.3:5060;branch=z9hG4bK123456789
Cseq: 101
.
.
.

<REGISTER F13>
Via: asterisk@192.168.0.3:5060;branch=z9hG4bK123456789
Cseq: 102
.
.
.

Like the above-mentioned flow, since branch of <REGISTER F11> and Via is the same value, <REGISTER F13> and <REGISTER F15> are judged to be resendings of <REGISTER F11>, and go wrong.

edited on: 06-07-04 22:10
By: Mark Spencer (markster) 2004-06-08 16:31:21

Okay thank you for the explanation.  I cannot duplicate this problem in CVS head, are you sure you're really running latest CVS head?

Here is my result:

Reliably Transmitting:
REGISTER sip:xxx.digium.com SIP/2.0
Via: SIP/2.0/UDP 216.207.245.34:5060;branch=z9hG4bK13aa1948
From: <sip:xxx@xxx.digium.com>;tag=as507ed7ab
To: <sip:xxx@xxx.digium.com>
Call-ID: 6b8b4567327b23c6643c986966334873@216.207.245.34
CSeq: 102 REGISTER
User-Agent: Asterisk PBX
Expires: 120
Contact: <sip:s@216.207.245.34>
Event: registration
Content-Length: 0

Sip read:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 216.207.245.34:5060;branch=z9hG4bK13aa1948
From: <sip:xxx@xxx.digium.com>;tag=as507ed7ab
To: <sip:xxx@xxx.digium.com>;tag=as05e5f52f
Call-ID: 6b8b4567327b23c6643c986966334873@216.207.245.34
CSeq: 102 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:xxx@216.207.245.8>
Content-Length: 0

Sip read:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 216.207.245.34:5060;branch=z9hG4bK13aa1948
From: <sip:xxx@xxx.digium.com>;tag=as507ed7ab
To: <sip:xxx@xxx.digium.com>;tag=as05e5f52f
Call-ID: 6b8b4567327b23c6643c986966334873@216.207.245.34
CSeq: 102 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:xxx@216.207.245.8>
Proxy-Authenticate: Digest realm="asterisk", nonce="3641ec74"
Content-Length: 0

Reliably Transmitting:
REGISTER sip:xxx.digium.com SIP/2.0
Via: SIP/2.0/UDP 216.207.245.34:5060;branch=z9hG4bK71269015
From: <sip:xxx@xxx.digium.com>;tag=as507ed7ab
To: <sip:xxx@xxx.digium.com>
Call-ID: 6b8b4567327b23c6643c986966334873@216.207.245.34
CSeq: 103 REGISTER
User-Agent: Asterisk PBX
Proxy-Authorization: Digest username="handytone", realm="asterisk", algorithm="MD5", uri="sip:xxx@216.207.245.8", nonce="3641ec74", response="2046e2d1a460ee5faecbc335acfb09a9", opaque=""
Expires: 120
Contact: <sip:s@216.207.245.34>
Event: registration
Content-Length: 0

As you can see the branch parameters are different here.
By: nakata (nakata) 2004-06-08 20:11:47

Yes. Of course, before contributing here, the newest version is re-installed and it is checking that it is the same operation.

However, surely your result differs from my result.
Well ... The difference in a response code is worrisome for a while.

Although this is a question, P.184-21.4.2 of RFC3261 is describing "401 Unauthorized" response is issued by UASs and registrars, while "407 Proxy Authentication Required" is used by proxy servers.
"401 Unauthorized" regards the attestation demand response to REGISTER.
Why do you use "407 Proxy Authentication Required"?

At once, I change and experiment in a response code on "407 Proxy Authentication Required." The report difference will have been carried out if an experiment result comes out.
By: Olle Johansson (oej) 2004-06-09 11:35:02

407 is issued when we get no authorization from the UA, but wan't to get an authorization to allow access.

401 is issued when we get an authorization but it doesn't match the credentials (i.e. secret) we have. It's a final response.
By: Olle Johansson (oej) 2004-06-09 11:36:33

So we *need* to see your full SIP DEBUG output in order to help you find out if this is a configuration issue or a bug. Also check if the "pedantic=yes" setting of sip.conf helps you.
By: nakata (nakata) 2004-06-09 21:16:30

Thank you  oej  for a reply.

P.4 of RFC3665 (SIP Basic Call Flow Examples) and item 2.1.Successful New Registration are in the present defact standard.

I am also checking that operation of Asterisk is operation which you say. For the moment, I cannot be checking the sentence by which the operation was clearly written to be "in violation" on RFC. Although it does not say that the operation is mistaken for the reason, isn't disregarding and mounting a defact standard good?

The result was the same although the examination which changes a response code and an attestation demand header with it on the other day, and answers was carried out. The same branch was resent.

Although he wanted to check about a version at once, and it seems that there were the Release version, a Stable version, and the Development version now, which version was meant? I thought that it was the thing of the Development version.
By: Mark Spencer (markster) 2004-06-12 11:18:35

Actually, he's right.  403 Forbidden is final, 401 is used by UAC's and registrars, while 407 is used for proxy auth.  *sigh* thanks again, SIP authors for adding meaningless additional drivel to the spec.
By: Mark Spencer (markster) 2004-06-12 11:34:46

Fixed in CVS head!
By: Digium Subversion (svnbot) 2008-01-15 14:57:59.000-0600

Repository: asterisk
Revision: 3195

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r3195 | markster | 2008-01-15 14:57:58 -0600 (Tue, 15 Jan 2008) | 3 lines

Use 401 Unauthorized instead of 407 Proxy Authentication required for REGISTER,
and use 403 for final request on proxy instead of 401 (bug ASTERISK-1773)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=3195