[Home]

Summary:ASTERISK-01026: REGISTER branch number not being incremented/changed after transaction
Reporter:sstillwell (sstillwell)Labels:
Date Opened:2004-02-11 19:16:39.000-0600Date Closed:2004-09-25 02:52:14
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip.diff
Description:After a REGISTER request, a 407 authorize request is received.  According to my VoIP provider, galaxyvoice.com, RFC 3261 requires that the branch change after a transaction.  * seems to be using the same branch ID when responding with an Authorization response

****** ADDITIONAL INFORMATION ******

I have patched my code (changes in channels/chan_sip.c), and I am able to register with the VoIP provider and receive calls.  Not sure how I should proceed from here.
Comments:By: Brian West (bkw918) 2004-02-11 23:18:27.000-0600

Please attach a diff -u of your changes and if you can find the section in RFC3261 and post that also.
By: sstillwell (sstillwell) 2004-02-12 00:13:23.000-0600

I will see if I can contact the ISP for the relevant section of the RFC, and look for it myself if they can't/won't tell me.  The change did make the difference between getting continual retries on REGISTER and a successful registration.
By: Olle Johansson (oej) 2004-02-12 01:47:35.000-0600

It is not very clear to me that this is *requested* by RFC3261. IT says that a proxy that wants to detect loops may change this. Asterisk doesn't really detect loops like this.

"If a proxy wishes to detect loops, the branch parameter it supplies MUST depend on all information
affecting processing of a request, including the incoming Request-URIand any header fields affecting
the request&ASTERISK-7996;s admission or routing. This is necessary to distinguish looped requests from requests
whose routing parameters have changed before returning to this server."

"The request method MUST NOT be included in the calculation of the branch parameter. In particular,
CANCEL and ACK requests (for non-2xx responses) MUST have the same branch value as the corresponding
request they cancel or acknowledge. The branch parameter is used in correlating those
requests at the server handling them (see Sections 17.2.3 and 9.2)."

A transaction is defined as:
"SIP is a transactional protocol: interactions between components take place in a series of independent
message exchanges. Specifically, a SIP transaction consists of a single request and any responses to that
request, which include zero or more provisional responses and one or more final responses."

So, as a I understand this, the "Auth required" response is not a *NEW* transaction, it's the same transaction as the REGISTER.

In the transaction part, the RFC states:
"A response matches a client transaction under
two conditions:
1. If the response has the same value of the branch parameter in the top Via header field as the branch
parameter in the top Via header field of the request that created the transaction.
2. If the method parameter in the CSeq header field matches the method of the request that created the
transaction. The method is needed since a CANCEL request constitutes a different transaction, but
shares the same value of the branch parameter."
My understanding is that if we change the branch, the response will not match the REGISTER and everyone will be confused...

I'm looking forward to the response from the ISP, so I understand more how they parse the RFC. I'm not that experience in SIP implementations, so don't read my quotes verbatim. It's a very large and complex RFC, so there may be contradictions or parts I've missed.
By: sstillwell (sstillwell) 2004-02-12 17:27:23.000-0600

http://www.ietf.org/rfc/rfc3261.txt?number=3261

Check 17.1.2.2, "Formal Description" and especially Figure 6 of that section.  The state diagram for a client transaction shows that any response 200 through 699 on a non-INVITE client transaction completes the transaction.  Therefore, a 407 response on a REGISTER ends the transaction and begins another one...this time REGISTERing with the Authorization header already in place.

Per the RFC:

"If a final response (status codes 200-699) is received while in the "Trying" state, the response MUST be passed to the TU, and the client transaction MUST transition to the "Completed" state."

and...

"If a final response (status codes 200-699) is received while in the "Proceeding" state, the response MUST be passed to the TU, and the client transaction MUST transition to the "Completed" state."

And in 17.1.3

"  When the transport layer in the client receives a response, it has to
  determine which client transaction will handle the response, so that
  the processing of Sections 17.1.1 and 17.1.2 can take place.  The
  branch parameter in the top Via header field is used for this
  purpose.  A response matches a client transaction under two
  conditions:

     1.  If the response has the same value of the branch parameter in
         the top Via header field as the branch parameter in the top
         Via header field of the request that created the transaction.

     2.  If the method parameter in the CSeq header field matches the
         method of the request that created the transaction.  The
         method is needed since a CANCEL request constitutes a
         different transaction, but shares the same value of the branch
         parameter."

So, if we are indeed in a new transaction, and we don't change the branch parameter, then we run the risk of being incorrectly matched with the previous transaction that could be in the "Completed" state, but not yet "Terminated".

Does that make sense?  Bear in mind that I'm really new to this.
By: sstillwell (sstillwell) 2004-02-12 17:29:39.000-0600

I just noticed that my patch does not deal with state changes in transactions...I just change the branch parameter.

That's probably bad, isn't it?

I knew it was too easy..
By: Olle Johansson (oej) 2004-02-15 02:48:55.000-0600

Sorry for my comments above, I mistakenly reasoned based on registering with Asterisk, not for Asterisk registering with outside proxies. I'll do some testing on this scenario.
By: Mark Spencer (markster) 2004-04-02 12:27:30.000-0600

I believe this is already fixed, can you confirm?
By: sstillwell (sstillwell) 2004-04-02 23:50:38.000-0600

I no longer have Asterisk up and running, I had to reformat the machine for another use.  I'm sorry, but I cannot confirm that it's fixed or broken...

Anybody?  The VOIP provider that I was having problems with was Galaxy Voice (http://www.galaxyvoice.com).

Sorry, guys...
By: Mark Spencer (markster) 2004-04-08 01:07:18

Fixed in CVS