[asterisk-bugs] [JIRA] (ASTERISK-29470) sip_to_pjsip script improperly combines registration config

[Kevin Harwell (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Harwell updated ASTERISK-29470:
-------------------------------------

    Description: 
Major bug in this script, though probably minor overall as far as Asterisk is concerned:

the pjsip_to_sip script does not properly parse configuration where multiple registrations exist with the same server or provider.

This is example output from running the script - clearly nonsensical:
{noformat}
[reg_callcentric.com]
type = registration
retry_interval = 20
max_retries = 10
contact_user = callcentric
contact_user = callcentrict2
expiration = 120
transport = transport-udp
outbound_auth = auth_reg_callcentric.com
client_uri = sip:1 at callcentric.com
client_uri = sip:2 at callcentric.com
server_uri = sip:callcentric.com

[auth_reg_callcentric.com]
type = auth
password = t
password = f
username = 1
username = 2

[reg_freedid.ipcomms.net]
type = registration
retry_interval = 20
max_retries = 10
contact_user = ipcomms
contact_user = ipcomms2
expiration = 120
transport = transport-udp
outbound_auth = auth_reg_freedid.ipcomms.net
client_uri = sip:1 at freedid.ipcomms.net
client_uri = sip:2 at freedid.ipcomms.net
server_uri = sip:freedid.ipcomms.net

[auth_reg_freedid.ipcomms.net]
type = auth
password = 1
password = 2
username = 1
username = 2
{noformat}
The above is clearly nonsense, but PJSIP generates no errors from this configuration and one of the registrations will succeed, making it appear as though all is dandy when in fact most of the configuration is likely broken or non-existent as far as PJSIP is concerned.

This is created from the corresponding sip.conf:
{noformat}
register => 1:x at callcentric.com/callcentric
register => 2:y at callcentric.com/callcentrict2

[callcentric]
type=peer
context=from-callcentric
host=callcentric.com
fromdomain=callcentric.com
defaultuser=1
fromuser=1
secret=x
insecure=port,invite
disallowed_methods=UPDATE
directmedia=no
videosupport=no
disallow=all
allow=g722
allow=ulaw

[callcentrict2]
type=peer
context=from-callcentric
host=callcentric.com
fromdomain=callcentric.com
defaultuser=2
fromuser=2
secret=y
insecure=port,invite
disallowed_methods=UPDATE
directmedia=no
videosupport=no
disallow=all
allow=g722
allow=ulaw
{noformat}

  was:
Major bug in this script, though probably minor overall as far as Asterisk is concerned:

the pjsip_to_sip script does not properly parse configuration where multiple registrations exist with the same server or provider.

This is example output from running the script - clearly nonsensical:

[reg_callcentric.com]
type = registration
retry_interval = 20
max_retries = 10
contact_user = callcentric
contact_user = callcentrict2
expiration = 120
transport = transport-udp
outbound_auth = auth_reg_callcentric.com
client_uri = sip:1 at callcentric.com
client_uri = sip:2 at callcentric.com
server_uri = sip:callcentric.com

[auth_reg_callcentric.com]
type = auth
password = t
password = f
username = 1
username = 2

[reg_freedid.ipcomms.net]
type = registration
retry_interval = 20
max_retries = 10
contact_user = ipcomms
contact_user = ipcomms2
expiration = 120
transport = transport-udp
outbound_auth = auth_reg_freedid.ipcomms.net
client_uri = sip:1 at freedid.ipcomms.net
client_uri = sip:2 at freedid.ipcomms.net
server_uri = sip:freedid.ipcomms.net

[auth_reg_freedid.ipcomms.net]
type = auth
password = 1
password = 2
username = 1
username = 2

The above is clearly nonsense, but PJSIP generates no errors from this configuration and one of the registrations will succeed, making it appear as though all is dandy when in fact most of the configuration is likely broken or non-existent as far as PJSIP is concerned.

This is created from the corresponding sip.conf:

register => 1:x at callcentric.com/callcentric
register => 2:y at callcentric.com/callcentrict2

[callcentric]
type=peer
context=from-callcentric
host=callcentric.com
fromdomain=callcentric.com
defaultuser=1
fromuser=1
secret=x
insecure=port,invite
disallowed_methods=UPDATE
directmedia=no
videosupport=no
disallow=all
allow=g722
allow=ulaw

[callcentrict2]
type=peer
context=from-callcentric
host=callcentric.com
fromdomain=callcentric.com
defaultuser=2
fromuser=2
secret=y
insecure=port,invite
disallowed_methods=UPDATE
directmedia=no
videosupport=no
disallow=all
allow=g722
allow=ulaw


> sip_to_pjsip script improperly combines registration config
> -----------------------------------------------------------
>
>                 Key: ASTERISK-29470
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29470
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 18.4.0
>            Reporter: N A
>
> Major bug in this script, though probably minor overall as far as Asterisk is concerned:
> the pjsip_to_sip script does not properly parse configuration where multiple registrations exist with the same server or provider.
> This is example output from running the script - clearly nonsensical:
> {noformat}
> [reg_callcentric.com]
> type = registration
> retry_interval = 20
> max_retries = 10
> contact_user = callcentric
> contact_user = callcentrict2
> expiration = 120
> transport = transport-udp
> outbound_auth = auth_reg_callcentric.com
> client_uri = sip:1 at callcentric.com
> client_uri = sip:2 at callcentric.com
> server_uri = sip:callcentric.com
> [auth_reg_callcentric.com]
> type = auth
> password = t
> password = f
> username = 1
> username = 2
> [reg_freedid.ipcomms.net]
> type = registration
> retry_interval = 20
> max_retries = 10
> contact_user = ipcomms
> contact_user = ipcomms2
> expiration = 120
> transport = transport-udp
> outbound_auth = auth_reg_freedid.ipcomms.net
> client_uri = sip:1 at freedid.ipcomms.net
> client_uri = sip:2 at freedid.ipcomms.net
> server_uri = sip:freedid.ipcomms.net
> [auth_reg_freedid.ipcomms.net]
> type = auth
> password = 1
> password = 2
> username = 1
> username = 2
> {noformat}
> The above is clearly nonsense, but PJSIP generates no errors from this configuration and one of the registrations will succeed, making it appear as though all is dandy when in fact most of the configuration is likely broken or non-existent as far as PJSIP is concerned.
> This is created from the corresponding sip.conf:
> {noformat}
> register => 1:x at callcentric.com/callcentric
> register => 2:y at callcentric.com/callcentrict2
> [callcentric]
> type=peer
> context=from-callcentric
> host=callcentric.com
> fromdomain=callcentric.com
> defaultuser=1
> fromuser=1
> secret=x
> insecure=port,invite
> disallowed_methods=UPDATE
> directmedia=no
> videosupport=no
> disallow=all
> allow=g722
> allow=ulaw
> [callcentrict2]
> type=peer
> context=from-callcentric
> host=callcentric.com
> fromdomain=callcentric.com
> defaultuser=2
> fromuser=2
> secret=y
> insecure=port,invite
> disallowed_methods=UPDATE
> directmedia=no
> videosupport=no
> disallow=all
> allow=g722
> allow=ulaw
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)