baresip: From URI does not match AoR

My account is like this:

--- sip:test%401@foo.bar ---
 nrefs:     1
 cuser:     test%401-0x55ab26979e70
 pub-gruu:  
 Supported: gruu,path,outbound,replaces,norefersub

Account:
 address:      <sip:test%401@foo.bar>;audio_codecs=PCMU,PCMA;regint=0;pubint=0;...
 luri:         sip:test%401@foo.bar
 aor:          sip:test%401@foo.bar

When the UA makes a call, From header looks like this:

INVITE sip:bar@test.tutpro.com SIP/2.0
Via: SIP/2.0/TCP 192.168.188.215:5020;branch=z9hG4bK986088d8c51fb5b6;rport
Contact: <sip:test%401-0x55ab26979e70@192.168.188.215:5020;transport=tcp>
Max-Forwards: 70
To: <sip:bar@test.tutpro.com>
From: <sip:test%25401@foo.bar>;tag=e0f802f01da481de

The AoR has character @ that according to RFC 3261 needs to be escaped and written as %40.

Why is the escape prefix % escaped?

About this issue

Original URL
State: closed
Created a year ago
Comments: 32 (10 by maintainers)

Most upvoted comments

@juha-h I had another discussion with @cspiel1, we agreed to revert my recent URI escaping commits to restore the old behavior. We will make sure to enter escaped URIs into BareSIP.

I apologize for causing breaks, we were not fully aware of how others used BareSIP.

maximilianfridrich on May 11, 2023

Maximilian Fridrich writes:

@juha-h We implemented the escaping exactly because we want to be RFC compliant. The only issue we are having is whether the input into BareSIP like creating accounts, contacts, etc. is already escaped or not. We will always be RFC compliant.

This question needs to be answered: Does BareSIP expect escaped input or unescaped input?

My understanding is that each line in accounts file is a SIP URI that follows SIP URI syntax. If it is not a SIP URI, then accounts file could be, for example, an xml file.

But it would be fine with me to have a config variable that tells if AoR user follows RFC3261 syntax or follows some other syntax that is described in the Wiki. The “some other syntax” must also allow @ character in AoR user.

juha-h on May 11, 2023

Due to the complexity of URI escaping we should at least offer an UTF-8 compatible uanew command and account file parsing in module account. Maybe activate/deactivate the escaping via a config option?

cspiel1 on May 9, 2023

Again, we interpreted the text in the accounts file or the string received by the command uanew as raw, unescaped strings. Your interpretation is probably valid too, and maybe would be better/easier.

Keep in mind though that this means your application needs to know the RFC quite well too, and the BNF is not trivial. Further, it needs to know exactly how the URIs are assembled and sent if there are different fields for user, host, display name etc - e.g. if the display name is sent with double quotes around it or not. See:

      UTF8-NONASCII   =  %xC0-DF 1UTF8-CONT
                      /  %xE0-EF 2UTF8-CONT
                      /  %xF0-F7 3UTF8-CONT
                      /  %xF8-Fb 4UTF8-CONT
                      /  %xFC-FD 5UTF8-CONT
      UTF8-CONT       =  %x80-BF

      quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
      qdtext         =  LWS / %x21 / %x23-5B / %x5D-7E
                        / UTF8-NONASCII
      quoted-pair  =  "\" (%x00-09 / %x0B-0C
                      / %x0E-7F)

      display-name   =  *(token LWS)/ quoted-string

      name-addr      =  [ display-name ] LAQUOT addr-spec RAQUOT
      addr-spec      =  SIP-URI / SIPS-URI / absoluteURI
      display-name   =  *(token LWS)/ quoted-string

I am not sure what the correct interpretation of the accounts file and uanew argument is. Could someone else chime in? @alfredh @sreimers

maximilianfridrich on May 9, 2023