[Home]

Summary:ASTERISK-12117: chan_sip creates a new local tag (from-tag) for every register message
Reporter:Pawel Pierscionek (urtho)Labels:
Date Opened:2008-05-30 15:32:51Date Closed:2013-11-08 16:56:04.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Registration
Versions:Frequency of
Occurrence
Related
Issues:
causesASTERISK-22946 Local From tag regression with sipgate.de
Environment:Attachments:
Description:refreshing from-tag for each register message - even within the same dialog is against RFC.

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

from-tag should be consistent within a dialog otherwise some SIP validators/firewalls/proper proxies might drop  the register message as it does not follow RFC.

sipXecs is such an example.

removing the chan_sip.c line that contains the comment
"create a new local tag for every register attempt" seems to solve the problem.
Comments:By: Raj Jain (rjain) 2008-05-30 17:50:53

I'm not sure what's the basis of this bug report. Please quote the sections of any RFCs where this is stated.

A register request does not form a dialog and thus the from-tag can be different in different registration refresh requests. I'll quote section 10.2 of RFC 3261:

A REGISTER request does not establish a dialog.
By: Pawel Pierscionek (urtho) 2008-06-01 13:37:42

my bad with the REGISTER being a dialog :(

IMHO chan_sip does not follow the SHOULD clause of RFC 3261, section 8.1.3.5.

>This new request constitutes a new transaction and SHOULD have the same value >of the Call-ID, To, and From of the previous request, but the CSeq should >contain a new sequence number that is one higher than the previous.
By: Raj Jain (rjain) 2008-06-01 14:57:20

That section of RFC 3261 talks about how a UAC should construct a subsequent request on receiving some particular kinds of 4XX responses. It does not talk about registration refresh requests. You probably meant to refer to a scenario where Asterisk receives a 401/407 response to an outbound REGISTER request and then when it resubmits the REGISTER, it changes the from-tag in it.

Technically, it's a SHOULD clause on the UAC so if a UAS/Proxy is not able to handle from-tag change then the bug is in that entity. However, I agree that this is something that can be improved upon in Asterisk. This just doesn't apply to REGISTER method but other methods as well.
By: Olle Johansson (oej) 2008-07-01 09:13:48

In section 10.2.4 I find the following:
"A UA SHOULD use the same Call-ID for all registrations during a single boot cycle. Registration refreshes
SHOULD be sent to the same network address as the original registration, unless redirected."

I don't find any information about the requirement of a tag to be the same. That's only a requirement within a dialog, and as rjain has pointed out, RFC3261 clearly states that REGISTER is not a dialog.

Suspending this bug report since we have had no responses or comments from the reporter for a month.
By: Matt Jordan (mjordan) 2013-05-06 15:50:36.493-0500

Re-opening per discussion on #asterisk-dev.
By: Matt Jordan (mjordan) 2013-05-06 15:52:28.117-0500

Pertinent discussion:

{noformat}
(03:33:23 PM) jsmith: Seems we're generating a new from-tag for each REGISTER request
(03:33:48 PM) file: I know the call id is supposed to be the same, but I don't remember reading that the tag has to be
(03:34:41 PM) jsmith: Someone referenced RFC 3261, section 8.1.3.5.
(03:34:46 PM) jsmith: I guess I should go look that up
(03:35:12 PM) putnopvut: Just got back into the office and catching up on this conersation
(03:36:00 PM) jsmith: Ah, specifically "This new request
(03:36:00 PM) jsmith:    constitutes a new transaction and SHOULD have the same value of the
(03:36:00 PM) jsmith:    Call-ID, To, and From of the previous request, but the CSeq should
(03:36:00 PM) jsmith:    contain a new sequence number that is one higher than the previous."
(03:36:21 PM) jsmith: putnopvut: No worries -- just looking for another set of eyes on this
(03:37:32 PM) ***jsmith thinks that we should have more SHOULDs and more MUSTs in SIP
(03:38:01 PM) saghul_ [~saghul@ip3e830637.speed.planet.nl] entered the room.
(03:38:15 PM) putnopvut: SHOULD is my least favorite RFC word
(03:38:33 PM) putnopvut: And in close second is RECOMMENDED, only because it's used less.
(03:39:13 PM) mjordan: correct me if I'm wrong, but tags would affect dialogs, whereas this is a REGISTER request
(03:39:40 PM) jsmith: mjordan: Correct, and REGISTERs don't begin a dialog, right?
(03:40:30 PM) alecdavis [~alecdavis@202.36.76.21] entered the room.
(03:40:31 PM) mjordan: jsmith: no, but I have a feeling that even though this isn't a dialog, we should still be sending a from tag. Since the From header should remain unchanged in a re-transmit, that would imply that it needs to be the same tag (I think)
(03:40:47 PM) putnopvut: But section 8 is general UAS behavior. It doesn't pertain necessarily to dialogs.
(03:40:55 PM) mjordan: right. I'm backtracking now
(03:41:02 PM) putnopvut: So for REGISTER, the recommendation in section 8 should be pertinent
(03:41:12 PM) mjordan: and even non-dialogs have From tags
(03:41:19 PM) jsmith: mjordan: Right... here's what I'm seeing.  Asterisk tries to register (initial registration).  Server comes back with a 401 auth required.
(03:41:37 PM) putnopvut: I don't think the problem is that we don't include a from-tag. It's that we change it on subsequent retries.
(03:41:37 PM) jsmith: mjordan: We re-attempt the REGISTER with auth, but with a different from-tag.
(03:41:53 PM) pabelanger [~pabelange@asterisk/contributor-and-bug-marshal/pabelanger] entered the room.
(03:41:53 PM) mode (+o pabelanger) by ChanServ
(03:43:04 PM) jsmith: The server says something to the effect of "The from-tag in the request I sent the nonce to doesn't match the from-tag on the new request", and denies the registration
(03:43:13 PM) jsmith: putnopvut: That's my understanding as well
(03:45:54 PM) putnopvut: Well, to be fair to Asterisk, it's only SHOULD strength that we keep the from-tag the same according to 8.1.3.5.
(03:46:01 PM) putnopvut: (See why I hate SHOULD ?)
(03:46:35 PM) jsmith: So, ignore and keep requiring people to patch?  Fix?  Expose via an option?
(03:46:40 PM) putnopvut: But, if it's really an easy fix like that e-mail implies, we may as well make it to be more compliant since apparently some endpoints will refuse our auth.
(03:46:52 PM) jsmith: It's a one-line removal
(03:47:05 PM) ***jsmith is happy to submit a patch
{noformat}