[Home]

Summary:ASTERISK-00706: [patch] Custom User-Agent
Reporter:barton (barton)Labels:
Date Opened:2003-12-25 23:29:18.000-0600Date Closed:2008-01-15 14:56:11.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) patch_useragent.txt
Description:This patch allows the user to specify a custom User-Agent with each "Register" command in sip.conf.  The format is:
user[:secret[:authuser]]@host[:port[:useragent]][/contact]
Comments:By: barton (barton) 2003-12-26 00:16:45.000-0600

diff -u added
By: muckl (muckl) 2004-01-10 22:48:51.000-0600

Tested, works fine here with:

register => herlitz:XXX:herlitz@iptel.org:5060:Cisco 7960/4777


This results in:

Session Initiation Protocol
   Request line: REGISTER sip:iptel.org SIP/2.0
       Method: REGISTER
   Message Header
       Via: SIP/2.0/UDP 217.84.205.119:5060;branch=z9hG4bK2ed78aca
       From: <sip:herlitz@iptel.org>;tag=as57603703
       To: <sip:herlitz@iptel.org>
       Call-ID: 15c6c2ff62b27cbb7627fc10745f2793@10.0.0.1
       CSeq: 102 REGISTER
       User-Agent: Cisco 7960
       Expires: 120
       Contact: <sip:4777@217.84.205.119>
       Event: registration
       Content-length: 0
By: jrollyson (jrollyson) 2004-01-11 04:41:03.000-0600

Why? Any implementation braindead enough to require a specific UA is horribly broken anyway.
By: barton (barton) 2004-01-11 13:08:53.000-0600

"Why? Any implementation braindead enough to require a specific UA is horribly broken anyway"

The UA can be used as a rudimentary method of identification.  You simply have not found the need for this patch yet.  Others, including myself, have.
By: barton (barton) 2004-01-13 15:04:31.000-0600

The patch has been modified to additionally allow a user to specify a custom User-Agent within a service definition in sip.conf.  For example:

[fwd.pulver.com]
type=friend
secret=mypassword
username=my fwd number
host=fwd.pulver.com
fromdomain=fwd.pulver.com
useragent=my custom user agent
By: Brian West (bkw918) 2004-01-14 00:57:27.000-0600

Accually the cisco 7960 will be CSCO/4 CSCO/5 or CSCO/6 does this patch take /'s in the agent into account or does it just ignore them?
By: barton (barton) 2004-01-14 09:19:34.000-0600

Excellent point.  There would be problems with this:
user:secret:authuser@host:port:user/agent

But perhaps not this:
user:secret:authuser@host:port:user/agent/contact

We could require the user to escape all delimeters individually:
user:secret:authuser@host:port:user\/agent/contact

Or require them to delimit the string:
user:secret:authuser@host:port:"user/agent"/contact

How is a ":" in the user, secret, and authuser strings handled?
By: Brian West (bkw918) 2004-01-14 20:01:01.000-0600

The last option seems to be the best.  Can we make this patch do that?
By: barton (barton) 2004-01-15 08:53:07.000-0600

I was thinking that escaping the delimeter, no matter what it is, would be the most flexible method.  If a : appears in the user, secret, or authuser strings it will confuse the existing parsing as well.  If the code is rewritten to allow escaping of both : and / and not require quote-delimiters then it won't break existing register directives.  The user would then be free to use " in the user agent, which they would otherwise have to escape in some manner.
By: John Todd (jtodd) 2004-01-20 10:48:23.000-0600

also implemented in http://bugs.digium.com/bug_view_page.php?bug_id=0000759
By: Olle Johansson (oej) 2004-03-21 11:27:42.000-0600

Need a delimiter - is that patch update on it's way?
By: Brian West (bkw918) 2004-04-17 00:39:56

about this:

defaultuseragent="Asterisk PBX"
useragent1=Blah1
useragent2=Blah2
useragent3=Blah3
useragent4=Blah4
useragent5=Blah5

Then use use register => user:pass@proxy:port:useragentX/exten

bkw
By: Olle Johansson (oej) 2004-04-17 02:07:21

...is this code disclaimed?
By: Brian West (bkw918) 2004-04-26 13:03:35

updates?
By: twisted (twisted) 2004-04-29 23:14:55

Status check on bug 712... status check on bug 712...
By: khb (khb) 2004-04-30 17:01:04

I have found it indeed useful to change the useragent string for special custom identification purposes.
But I really don't agree with the proposed placement of this user agent string.
The useragent label is clearly an identification of the local asterisk and not of the target host of registration and therefore should not be attached to the domainname in the statement.  If placed in the register statement at all it should be associated with the user identification tokens of the statement such as username:secret:authuser:useragent@proxy:port etc.
If implemented the proposed way you just create a spagetti pile of config options without much logical organization.
In my running versions of chan_sip I have a useragent option in the [general] section of the config file, where it make a lot more sense to me, since I don't know why I would want to make it different for different peers.  But mileage varies, and if so, an acceptable alternative appears to be the placement in a peer/user definition.

In connection with this, you could also add a callerid or displayname string for the registration statement, such as username:secret:authuser:displayname:useragent@foo.org

A valid addition to the end of the hostname:port would be an outboundproxyhost:port token.  I have a fully working implementation of o/b proxy support  that uses the register string
 <usertokens>@realm@ouboundproxy:port

Cheers

edited on: 04-30-04 16:01
By: Brian West (bkw918) 2004-05-01 00:41:27

Their is NO good solution for this the way we currently do register's

Now if we changed how we register then it would be sweet.
By: khb (khb) 2004-05-01 10:06:00

bkw918, please enlighten me with your thoughts offline or on the dev list.
By: Mark Spencer (markster) 2004-05-01 10:50:24

If we were to allow the user-agent to be overriden it would likely need to be on a per-peer or per-user or global basis.
By: Brian West (bkw918) 2004-05-01 17:05:53

Well we would have to tie the register => line to a peer entry.

register => user@peername

[peername]
blah=blah



bkw
By: Mark Spencer (markster) 2004-05-01 18:27:50

I think it already does.
By: khb (khb) 2004-05-01 21:27:02

Well, right now the register line directly creates a registry entry without attaching to a particular peer.
In my still experimental version of outbound proxy, which does work fine with FWD's o/b proxy, I still have a 'register' line and that doesn't need to have a peer defined.  But I also have a "shouldregister=yes/no" option in the peer definitions if you want to register the Asterisk with that peer. It simply takes info from the peer options and constructs a register compatible string and submits the registration via sip_register in the normal way.
With that the 'register' line is almost obsolete, since you probably always want a peer or friend definition for a host that you register with.
I will extract my implementation into a patch at some point when I have sorted out my thoughts and produced some documentation as well.
By: Brian West (bkw918) 2004-05-01 21:59:21

register=yes|no

this needs to work for iax and sip and everything else that registers.. it would be more elegant.

bkw
By: khb (khb) 2004-05-01 22:31:23

no problem,
The only messy part, IMHO, is the whole way that usernames, peernames and authentication is handled right now for peers and users, see also the patches that were done and reverted, ASTERISK-1421 and 1533. Does anyone have any documentation on what the design model was for users and peers?  The more I work with this code the more I think to abandon the distinction altogether.  I have read that users only send calls and peers receive them, but that's not true for sure.
By: Olle Johansson (oej) 2004-05-03 02:39:42

register=> indeed matches a peer if one exist with the same name.

Also, check the start of implementation of outbound proxy in chan_sip2 so we don't code two different implementations...

We also need to use the new authuser option added by mark in a recent patch.
By: Brian West (bkw918) 2004-05-05 01:39:37

ok lets get a patch worked up so we can test?
By: Mark Spencer (markster) 2004-05-05 10:18:48

I have to ask though, what's the practical use of this?
By: khb (khb) 2004-05-05 13:17:18

Ok, I am attaching a simple patch,  patch_useragent.txt
This represents the extent to which I propose you should go with this useragent business.  Simple global config file option to set
useragent=some custom name

I recommend AGAINST messing with the syntax of the register line at this time. This seems like a niche config desire, and if someone wants that they have the source to do it for themselves.
This patch presents a general and, IMHO, valid solution for those who want to label their UA with a custom vendor or network label.
The patch is designed so that one can compile in a default label with
-DDEFAULT_USERAGENT="\"my sip client\""
at compile time (it uses an #ifndef on DEFAULT_USERAGENT)
Cheers....
By: khb (khb) 2004-05-05 13:24:56

sorry, please ignore and delete the first patch file, the second one was the right one.
By: khb (khb) 2004-05-05 17:07:34

Forgot to answer Mark's question:  The use I see is for a vendor or network operator with varying versions of asterisk system to identify more easily who is running which SIP agent version by looking at the packet streams.  Many vendors of SIP clients put their software versions in there. With this we have the option to compile a version string in via -DDEFAULT_USERAGENT or have it in the configuration file.
By: Olle Johansson (oej) 2004-05-06 15:51:15

Ok. We have two different patches here. One that changes the useragent when we register with other hosts only, depending on the host. THis may be needed for stupid filters that disallow services for Asterisk, we might need to masquerade.
I think the config of the agent string in this case should be in the [peer] section that connects to the register, the register=> line is overloaded with this syntax.

The other patch makes the Asterisk user agent configurable in all SIP transactions, something that isn't really needed, unless I am missing something. We might add a function that adds a version indication, so that proxies can adopt to different versions of the SIP channel. The patch does not support that, and unless I'm missing something important, is something I can't see being used. Please enlighten me why you want to do that, now that I have told you why we might want to register with a different user agent only for that connection.
/O :-)
By: khb (khb) 2004-05-06 18:42:10

Well, the main thing I was really concerned about was the original proposal to add a niche configuration parameter with extremely narrow use to the register syntax and increasing the parameter confusion for most people even more. I am trying to write some major documentation, but explaining the existing jungle of options, their actual inner workings and inter-relations is dawnting. It's easy to just keep adding options here and there for every little reason and ache, but there should be overall goals & design concepts, and resulting from that a clear and orthogonal instruction set to accomplish the goals.  I haven't seen that here. The system gets built from fixes here and there, chasing operability and functionality, instead of top-down with a planning document and rollout plan.
As a result there is no documentation on how things should work and not.
In this particular patch case, the decision should be what do we want to support and how; then we see about best implementation.
If you want to support this on a peer to peer basis, I agree with you on putting it in [peer] section. I already stated the use I see. Personally, I don't see the need for peer specific configuration, or is there really anyone filtering and denying access based on user agent?  At times, I had believed that too, but it turned out to be some other technical issue.  To me the User Agent header should display the brand name of the agent and some version information for debugging purposes.  That's what all the other vendors do. If you want to put that into a config option or a static compile, that's an issue that needs to be decided, either through a team process or by the Fuehrer. :-)
bkw asked for a patch to test, so it's easy to generate many patches, but that doesn't solve the problem as you can see now. I think I also have a source version for peer only configuration, and quite a few other patches, but I am beginning to preach.
Perhaps you should just leave this as it is for now, it doesnt prevent anybody from fixing their own special hickups.  Perhaps we should have a depository of source patches (after all this is an open source project), for people that have special problems, such as being filtered by the reason of the user agent species,  but the patches wouldn't be "standard" Asterisk.  Then, over time it can be evaluated and debated what shall become standard.
I am still new in this circle of active contributors to Asterisk, spent some time evaluating for myself how I can best contribute and I hope to do so.
Been involved with voip/telephony, both as hobby and commercially, since the beginnings in the early 90.
Anyways,  I suspect Mark is going to make the decision about how this should go. I really have no strong preferences.  Is there a committee with odd membership that can take votes on such issuses?  ... Later, i am sure.
By: Brian West (bkw918) 2004-05-06 18:50:30

#asterisk-dev and #asterisk-bugs to hash it out.

bkw
By: Brian West (bkw918) 2004-05-06 20:10:01

I have been looking at the outbound register stuff and we in no way link it to a peer entry in sip.conf.   We pass a line number to the conf then build it but we don't pass anything or I can't see it.. anyone care to point this out?
By: Olle Johansson (oej) 2004-05-07 09:39:57

bkw: The actual registration is working by itself, but when the call comes in, we match as usual. If there's a matching user or peer, we'll take it.

The trick wanted here is really to combine users and outbound registrations. We register to receive calls, that's a user. So what we want is a user register=yes parameter and outbound credentials for registration within the [user] config.
By: Brian West (bkw918) 2004-05-07 20:50:16

I want to see this last patch in CVS because its a good idea!
By: Brian West (bkw918) 2004-05-07 20:55:43

Updated the patch for recent CVS
By: khb (khb) 2004-05-07 23:26:08

This "bug" track is about useragent.

I have a working implementation of outboundproxy.
I will extract it and patch it into current cvs, test it again,
and open a new track here.
But what is also important is some more testing against other operators,
which is underway,
and some documentation, which is underway also.
But please no rush.
By: twisted (twisted) 2004-05-08 00:27:58

This is nice, but what about a per-peer/user override?  This would be uber-helpful when dealing with places that try to lock you into their device based on UA.
By: khb (khb) 2004-05-08 05:19:05

I have opened new track for o/b proxy support.
See you there.
By: Brian West (bkw918) 2004-05-19 01:22:57

I wanna see this in.. I don't really care about per peer because we are what we are... why hide it... Come out of that closet and show your peers your User-Agent without fear! :P  User-Agent PRIDE!!!

har har har i'm being silly but I think this is good.
By: khb (khb) 2004-05-19 02:22:47

hahahaha, Useragent ahoy!
How patriotic to wave the flag !

edited on: 05-19-04 01:22
By: John Todd (jtodd) 2004-05-20 00:59:56

I'd like to see this be per-peer, as well.  Some (stupid) SIP providers still try to match on User-Agent: strings to allow or disallow access to their systems.  Also, some (not as stupid) systems will react differently with RTP proxying or other features when they see a User-Agent: that matches certain strings.  When in doubt, go with the more flexible option...
By: Mark Spencer (markster) 2004-05-25 01:23:02

Okay it's in as-is.  If someone wants to do a per-peer version they can open a new bug when they have a patch ready and not before.
By: Digium Subversion (svnbot) 2008-01-15 14:56:11.000-0600

Repository: asterisk
Revision: 3067

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r3067 | markster | 2008-01-15 14:56:11 -0600 (Tue, 15 Jan 2008) | 2 lines

Merge useragent patch (bug ASTERISK-706)

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

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