Register => problem

I’ve several VoIP providers connected to my asterisk and working fine (including SIP registration).
Recently I’ve found provider which perfectly meets my needs and wanted to add it to my setup.

There is one specific thing with its configuration. The user there is a user’s full email (like where domain of the email is different that domain of provider ( and its host address (

I’ve set register as follows:
register =>

but request created by asterisk (11.1) does not match my expectations (definetly because register string is wrong):

REGISTER SIP/2.0 Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK243ecc44 Max-Forwards: 70 From: <>;tag=as665ae51c To: <> Call-ID: 1d9cf9214ff2c96374a52bd544f2afcd@ CSeq: 103 REGISTER User-Agent: Asterisk PBX 11.1.0 Expires: 120 Contact: <sip:s@x.x.x.x:5060> Content-Length: 0

Clearly domain where asterisk is trying to register (first line of request) is not the one of provider (, but that of my corporartion ( Request is being correctly sent to

What should be correct format of register string in such case (different provider domain, host and user domain). Can anyone sent me example?

Thanks in advance.

@ is not legal in the user part of a SIP URI.

  unreserved  =  alphanum / mark
  mark        =  "-" / "_" / "." / "!" / "~" / "*" / "'"
                 / "(" / ")"
  escaped     =  "%" HEXDIG HEXDIG

user = 1*( unreserved / escaped / user-unreserved )
user-unreserved = “&” / “=” / “+” / “$” / “,” / “;” / “?” / “/”

You could try entering it in escaped format (%40). If Asterisk accepts and sends that, and they don’t accept it, they are asking you to use an illegal URI.

You could also try the callback extension way of doing registers.

Replacing @ with %40 in registeration resulted with following message

REGISTER SIP/2.0 Via: SIP/2.0/UDP;branch=z9hG4bK15a8fe37 Max-Forwards: 70 From: <>;tag=as2160a3c2 To: <> Call-ID: 764e4f9c4795d84852f4c44d748f80d2@ CSeq: 102 REGISTER User-Agent: Asterisk PBX 11.1.0 Expires: 120 Contact: <sip:s@x.x.x.x:5060> Content-Length: 0

I’ve installed client provided by VOIP provider and captured their registration message. So expected output should be:

REGISTER SIP/2.0 From:user<>;tag=2900324631353641B3A60400 To:jnitecki<> Contact:sip:user@x.x.x.x:24764 User-Agent:SonetelClient Expires:3600 Call-ID:020316EB8781400000000000@test Max-Forwards:70 CSeq:1 REGISTER Via:SIP/2.0/UDP x.x.x.x:24764;branch=z9hG4bK49DA9ED0E441CF4BC0F6A21FEBE38264;rport; Content-Length:0

They are also stating that many third party clients (including Ekiga, X-Lite) as well as asterisk works fine with their setup. So it have to be something wrong in my configuration for registration.

If that would help I can install some other clients and provide capture of SIP messages as well.

In that case, the user name does not contain an @. My guess is that you need to configure a proxy.

After calling and “BYE”, the channels still remain and I can not clear the channel. I have a lot of WARNING regarding this in the “messages” file. Does anyone know how to solve this problem? (**** in the log is IP address or extension number)

shahidjee: Please don’t hijack other threads. Without a version, the assumption is you have an old version and the problem will be fixed by updating.

Do you mean to use Shall I put it in [General] section? Will it not affect all the other registration messages (rendering all other systems and devices unusable)?

What should be my register=> string in such way?

Apparently the provider is not compatible with SIP RFC, saddly it is also incompatible with Asterisk. So this is the PROVIDER issue and they need to address it. If I were you I would ask them if they can make an exception for you and give you a username without an @ character in it. I hope they will grant your wish.

They have provided an address of record, not a user name.

Your version of Asterisk does allow the full address of record to be specified, as well as the destination for the request.

This is probably not a proxy question, but if it were, proxy is settable by peer, and register can reference section names, or you can use callbackextension.

I would probably need to read the code to work out the full intended semantics of the second domain name.

Depending on the intent, there may be a bug that is not being noticed because most ITSPs ignore the domain in the INVITE.