sippy / b2bua Goto Github PK

Tested on two separate osx machines (Both yosemite), attempts to run b2bua produce the following error;-

$ b2bua_simple -f
('192.168.0.102', 5060)
Traceback (most recent call last):
  File "/usr/local/bin/b2bua_simple", line 9, in <module>
    load_entry_point('sippy==1.1.dev0', 'console_scripts', 'b2bua_simple')()
  File "build/bdist.macosx-10.11-x86_64/egg/sippy/b2bua_simple.py", line 146, in main_func
  File "build/bdist.macosx-10.11-x86_64/egg/sippy/SipTransactionManager.py", line 236, in __init__
  File "build/bdist.macosx-10.11-x86_64/egg/sippy/SipTransactionManager.py", line 124, in __init__
  File "build/bdist.macosx-10.11-x86_64/egg/sippy/Udp_server.py", line 38, in <module>
  File "build/bdist.macosx-10.11-x86_64/egg/sippy/Time/MonoTime.py", line 29, in <module>
  File "build/bdist.macosx-10.11-x86_64/egg/sippy/Time/clock_dtime.py", line 68, in <module>
  File "build/bdist.macosx-10.11-x86_64/egg/sippy/Time/clock_dtime.py", line 66, in find_symbol
Exception: Bah, clock_gettime cannot be found in libs ('c', 'rt') in the paths ('/usr/lib', '/lib')

Looking arround it appears clock_gettime does not exist on the mac, although there are other monotonic hight precision counters around, I'm not sure personally of how to fix it in a portable manner.

Any plan to have also the possibility to use TCP? Even better if also UDP to TCP (for packets bigger than 1300 bytes as described in RFC 3261) switch available.

C:\Users\Shivam\AppData\Local\Programs\Python\Python38-32\Scripts>b2bua_simple -f -n 192.168.0.105
Traceback (most recent call last):
File "c:\users\shivam\appdata\local\programs\python\python38-32\lib\runpy.py", line 193, in _run_module_as_main
return _run_code(code, main_globals, None,
File "c:\users\shivam\appdata\local\programs\python\python38-32\lib\runpy.py", line 86, in run_code
exec(code, run_globals)
File "C:\Users\Shivam\AppData\Local\Programs\Python\Python38-32\Scripts\b2bua_simple.exe_main.py", line 4, in
File "c:\users\shivam\appdata\local\programs\python\python38-32\lib\site-packages\sippy\b2bua_simple.py", line 29, in
from sippy.UA import UA
File "c:\users\shivam\appdata\local\programs\python\python38-32\lib\site-packages\sippy\UA.py", line 29, in
from sippy.UasStateIdle import UasStateIdle
File "c:\users\shivam\appdata\local\programs\python\python38-32\lib\site-packages\sippy\UasStateIdle.py", line 27, in
from sippy.Time.Timeout import TimeoutAbsMono
File "c:\users\shivam\appdata\local\programs\python\python38-32\lib\site-packages\sippy\Time\Timeout.py", line 32, in
from sippy.Core.EventDispatcher import ED2
File "c:\users\shivam\appdata\local\programs\python\python38-32\lib\site-packages\sippy\Core\EventDispatcher.py", line 38, in
from sippy.Time.MonoTime import MonoTime
File "c:\users\shivam\appdata\local\programs\python\python38-32\lib\site-packages\sippy\Time\MonoTime.py", line 35, in
from sippy.Time.clock_dtime import clock_getdtime, CLOCK_REALTIME, CLOCK_MONOTONIC
File "c:\users\shivam\appdata\local\programs\python\python38-32\lib\site-packages\sippy\Time\clock_dtime.py", line 81, in
clock_gettime = find_symbol('clock_gettime', ('c', 'rt'), ('/usr/lib', '/lib'))
File "c:\users\shivam\appdata\local\programs\python\python38-32\lib\site-packages\sippy\Time\clock_dtime.py", line 79, in find_symbol
raise Exception('Bah, %s cannot be found in libs %s in the paths %s' % (symname, lnames, paths))
Exception: Bah, clock_gettime cannot be found in libs ('c', 'rt') in the paths ('/usr/lib', '/lib')

Hi, Jev Björsell
I want to Implement a B2BUA in clearwater. My architecture is:
sprout(s-cscf) <---(Invite)----> B2BUA <---(Invite)---->SIP proxy (application server)
The SIP proxy just send message back to B2BUA and B2BUA send back the message to the s-cscf.
Can you tell me which script file (.py) should I test !?
And how to use it !?

thanks very much.

Hi, i get README and have Debian 9 OS.

Try to start b2bua_simple -f -n 10.125.184.2 but have error about missing module

  File "/usr/local/bin/b2bua_simple", line 11, in <module>
    load_entry_point('sippy==1.1.dev0', 'console_scripts', 'b2bua_simple')()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 561, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2631, in load_entry_point
    return ep.load()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2291, in load
    return self.resolve()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2297, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/local/lib/python2.7/dist-packages/sippy/b2bua_simple.py", line 29, in <module>
    from sippy.UA import UA
  File "/usr/local/lib/python2.7/dist-packages/sippy/UA.py", line 29, in <module>
    from sippy.UasStateIdle import UasStateIdle
  File "/usr/local/lib/python2.7/dist-packages/sippy/UasStateIdle.py", line 27, in <module>
    from sippy.Time.Timeout import TimeoutAbsMono
  File "/usr/local/lib/python2.7/dist-packages/sippy/Time/Timeout.py", line 32, in <module>
    from sippy.Core.EventDispatcher import ED2
  File "/usr/local/lib/python2.7/dist-packages/sippy/Core/EventDispatcher.py", line 41, in <module>
    from elperiodic.ElPeriodic import ElPeriodic

Then i install via pip this module from https://github.com/sobomax/libelperiodic but get error again about so file

  File "/usr/local/bin/b2bua_simple", line 11, in <module>
    load_entry_point('sippy==1.1.dev0', 'console_scripts', 'b2bua_simple')()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 561, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2631, in load_entry_point
    return ep.load()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2291, in load
    return self.resolve()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2297, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/local/lib/python2.7/dist-packages/sippy/b2bua_simple.py", line 29, in <module>
    from sippy.UA import UA
  File "/usr/local/lib/python2.7/dist-packages/sippy/UA.py", line 29, in <module>
    from sippy.UasStateIdle import UasStateIdle
  File "/usr/local/lib/python2.7/dist-packages/sippy/UasStateIdle.py", line 27, in <module>
    from sippy.Time.Timeout import TimeoutAbsMono
  File "/usr/local/lib/python2.7/dist-packages/sippy/Time/Timeout.py", line 32, in <module>
    from sippy.Core.EventDispatcher import ED2
  File "/usr/local/lib/python2.7/dist-packages/sippy/Core/EventDispatcher.py", line 41, in <module>
    from elperiodic.ElPeriodic import ElPeriodic
  File "/usr/local/lib/python2.7/dist-packages/elperiodic/ElPeriodic.py", line 36, in <module>
    _elpl = cdll.LoadLibrary('libelperiodic.so')
  File "/usr/lib/python2.7/ctypes/__init__.py", line 440, in LoadLibrary
    return self._dlltype(name)
  File "/usr/lib/python2.7/ctypes/__init__.py", line 362, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: libelperiodic.so: cannot open shared object file: No such file or directory

I cant make or else with it and cant find any info why it wont work how it looks in README on Debian 9.
Pls help me?

rtp_cluster and socket_server will be split out to their own independent repositories.

By default the nworkers attribute of Udp_server_opts is initialized with the value 30, from variable _DEFAULT_NWORKERS. It comes that during the Udp_server initialization, it spawns 30 senders and 30 receivers, each of them represented by a respective Thread (started in the constructor).

The only reason I could find for spawning these threads is due the synchronous name resolution performed by 'socket.getaddrinfo'.

A more modern approach is to delegate the name resolution to an appropriate asynchronous resolver, such as the one available on tornado, or on pycares. Of course, adequate profiling is desirable to demonstrate any optimization gain, but this latter approach would use less memory and would cause less overhead when processing bursts of incoming messages. Anyway, it will make the code far simpler and easier to maintain.

b2bua_simple.py won't run on Windows. It fails to start with the error: ImportError: No module named fcntl

SipLogger.py imports fcntl and syslog modules, which are available only under Linux/Unix platforms.

Python runtime provides msvcrt.locking method that is somewhat similar to fcntl.flock. So, it seems that making AsyncLogger.do_write working on both platforms is quite straightforward.

AsyncLoggerSyslog should be available only on platforms that have syslog, otherwise SIPLOG_BEND=syslog should be rejected (with warning) and defaulted to a file.

Dear team,
I was trying to use outbound_proxy sending as op in Routing, but seems like it is not working.
Any one put it on work?
The issue seems to be in source code as this variable is not read during a call.

Hope to get an answer.

Regards,

Hello.
Are there any plans to use asyncio in this nice project?

Signal.py and Timeout.py have a __main__ block that calls some self test code.

Extract test code, and port it into unittests'

Port the sh/diff based tests from sippy/self-test to the tests module.

Change the licenses under which sippy/b2bua is released from the GNU General Public License to the the BSD 2-Clause license.

Change applies to the SIP stack and rtp_cluster.

Not sure if latest versions support this. Adding SIP DNS SRV record support to B2BUA makes sense as more platforms / service providers go native cloud.

If there is no support for this already we would be happy to contribute this feature to b2bua.

From the RFC:

“The SRV RR allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and to designate some hosts as primary servers for a service and others as backups.”

If for some reason the ‘host’ with the highest priority cannot be reached, the SIP phone or proxy trying to reach the user within the domain will attempt to reach the next host defined within the SRV record

SipTransactionManager transparently handles client ACK to 200 OK and retransmissions of 200 OK in incomingResponse().

RFC6026 seems to indicate that the handling of ACK to 200 OK should be done by the TU.

My question: is this a deliberate design decision in b2bua to put creation of ACK in SipTransactionManager rather than leaving it to the business logic? (Maybe the UacStateRinging->UaStateConnected should be responsible for sending ACK?).

I can see that the current behaviour simplifies business logic as the ACK is handled at the lower level

RFC6026 Page 12:

When a 2xx response is received while in either the "Calling" or
"Proceeding" states, the client transaction MUST transition to the
"Accepted" state, and Timer M MUST be started with a value of
64*T1. The 2xx response MUST be passed up to the TU. The client
transaction MUST NOT generate an ACK to the 2xx response -- its
handling is delegated to the TU.

(In b2bua "Calling" == TRYING "Proceeding" == RINGING)

There is also a UACK state and t.uack property, is this meant for scripts that want to handle ACK generation on their own?

I did some tests with b2bua_simple (without rtp_proxy) and I noticed the Call_Id is the same between ingress and egress legs. In my understanding, a B2BUA should change it.

Introducing sippy_async: a monkey patch to run the event loop over
anyio 3, which means that the loop will support asyncio or trio.

I realised that this repo had moved from Twisted to a hand-crafted libelperiodic loop, but...
if you are using async python, I have an experimental monkey patch to support running the
event loop on asyncio/trio via anyio. Basic tests that pass: Timeout, Udp_server.

# runs the Timeout / Udp_server testsuites under anyio
python -m sippy_async

Implementation notes:

• does not use threads and the UDP server is implemented with anyio classes
• ED2.callFromThread() is not implemented as the network servers run on the event loop
• not all methods of Udp_server and EventDispatcher are implemented; only enough to run simple B2BUA scripts
  and some tests
• anyio has sync/async-type queues("memory object streams"): this enables callbacks that require async functionality (
  UDP data transmission, timeouts) to work without async creep; no function signatures are changed
• the curio async framework is not supported as this restriction is imposed by anyio 3

The pro would be that if you want to write your B2BUA scripts with async python you won't need to run two event loops.

Background info:

I'm trying to do a proof of concept where My Softphone at 192.168.44.1 registers to SIPpy at 192.168.44.3(test VM) using the realm [email protected].
SIPpy then passes on the register, modifying the realm to [email protected] (1.2.3.X)
rtpproxy is running, using unix socket.

The scenario I'm trying to solve is that I have some legacy sip servers that customers directly register to. I want to be able to simply drop sippy in as a replacement to these old servers and b2bua all traffic to new kamailio infrastructure. This way the client devices need no reconfiguration and I can make the move independent of them.

Issue:
Registration works fine however the invite seems to raise a Unicode error.
I'm running a fresh install of Centos7 (latest updates), python 2.7.5
selinux is permissive, no firewall

Log output
`[root@legacyproxy ~]# b2bua_otw_simple -f -l 192.168.44.3 -p 5060 -n sip.example.net.au -L /var/log/sippy.log
('sip.example.net.au', 5060)
04 Jun 06:16:36.319/GLOBAL/b2bua: RECEIVED message from 192.168.44.1:55245:
REGISTER sip:192.168.44.3 SIP/2.0
Via: SIP/2.0/UDP 192.168.44.1:55245;rport;branch=z9hG4bKPj8f0d561a94c5444eb42a5652cd0da4c9
Route: sip:192.168.44.3;lr
Max-Forwards: 70
From: sip:[email protected];tag=5458100f2dc44fdcb065314900298768
To: sip:[email protected]
Call-ID: 2b4f54b175bd4c4ebdde62d8847553c7
CSeq: 28989 REGISTER
User-Agent: MicroSIP/3.18.2
Contact: sip:[email protected]:55245;ob
Expires: 0
Content-Length: 0

REGISTER sip:192.168.44.3 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK39fb4807071a0178d7a4657b62accaa1;rport
Via: SIP/2.0/UDP 192.168.44.1:55245;branch=z9hG4bKPj8f0d561a94c5444eb42a5652cd0da4c9;rport=55245
Route: sip:192.168.44.3;lr
Max-Forwards: 70
From: sip:[email protected];tag=5458100f2dc44fdcb065314900298768
To: sip:[email protected]
Call-ID: 2b4f54b175bd4c4ebdde62d8847553c7
CSeq: 28989 REGISTER
User-Agent: MicroSIP/3.18.2
Contact: sip:[email protected]:55245;ob
Expires: 0
Content-Length: 0

04 Jun 06:16:36.327/GLOBAL/b2bua: SENDING message to sip.example.net.au:5060:
REGISTER sip:192.168.44.3 SIP/2.0
Via: SIP/2.0/UDP 192.168.44.3:5060;branch=z9hG4bK39fb4807071a0178d7a4657b62accaa1;rport
Via: SIP/2.0/UDP 192.168.44.1:55245;branch=z9hG4bKPj8f0d561a94c5444eb42a5652cd0da4c9;rport=55245
Route: sip:192.168.44.3;lr
Max-Forwards: 70
From: sip:[email protected];tag=5458100f2dc44fdcb065314900298768
To: sip:[email protected]
Call-ID: 2b4f54b175bd4c4ebdde62d8847553c7
CSeq: 28989 REGISTER
User-Agent: MicroSIP/3.18.2
Contact: sip:[email protected]:55245;ob
Expires: 0
Content-Length: 0

04 Jun 06:16:36.385/GLOBAL/b2bua: RECEIVED message from 1.2.3.68:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.44.3:5060;branch=z9hG4bK39fb4807071a0178d7a4657b62accaa1;rport=63230;received=203.55.174.123
Via: SIP/2.0/UDP 192.168.44.1:55245;branch=z9hG4bKPj8f0d561a94c5444eb42a5652cd0da4c9;rport=55245
From: sip:[email protected];tag=5458100f2dc44fdcb065314900298768
To: sip:[email protected];tag=9dd61ff61e802d8e2bef5f14621ef3c2.5c34
Call-ID: 2b4f54b175bd4c4ebdde62d8847553c7
CSeq: 28989 REGISTER
WWW-Authenticate: Digest realm="sip.example.net.au", nonce="WxTacFsU2USCyjLoANeeeoVhbKEUpMQs"
User-Agent: example-LB
Content-Length: 0

04 Jun 06:16:36.387/GLOBAL/b2bua: SENDING message to 192.168.44.1:55245:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.44.1:55245;rport=55245;branch=z9hG4bKPj8f0d561a94c5444eb42a5652cd0da4c9
From: sip:[email protected];tag=5458100f2dc44fdcb065314900298768
To: sip:[email protected];tag=9dd61ff61e802d8e2bef5f14621ef3c2.5c34
Call-ID: 2b4f54b175bd4c4ebdde62d8847553c7
CSeq: 28989 REGISTER
WWW-Authenticate: Digest realm="sip.example.net.au", nonce="WxTacFsU2USCyjLoANeeeoVhbKEUpMQs"
User-Agent: example-LB
Content-Length: 0

04 Jun 06:16:36.394/GLOBAL/b2bua: RECEIVED message from 192.168.44.1:55245:
REGISTER sip:192.168.44.3 SIP/2.0
Via: SIP/2.0/UDP 192.168.44.1:55245;rport;branch=z9hG4bKPj425267067e5f437ca66867b560c7efba
Route: sip:192.168.44.3;lr
Max-Forwards: 70
From: sip:[email protected];tag=5458100f2dc44fdcb065314900298768
To: sip:[email protected]
Call-ID: 2b4f54b175bd4c4ebdde62d8847553c7
CSeq: 28990 REGISTER
User-Agent: MicroSIP/3.18.2
Contact: sip:[email protected]:55245;ob
Expires: 0
Authorization: Digest username="7385", realm="sip.example.net.au", nonce="WxTacFsU2USCyjLoANeeeoVhbKEUpMQs", uri="sip:192.168.44.3", response="6cc3f02a9a62f8647eaa79dbbc
dc4d89"
Content-Length: 0

REGISTER sip:192.168.44.3 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bKf05857b0f7d8d29cce0b4981cfaeff7d;rport
Via: SIP/2.0/UDP 192.168.44.1:55245;branch=z9hG4bKPj425267067e5f437ca66867b560c7efba;rport=55245
Route: sip:192.168.44.3;lr
Max-Forwards: 70
From: sip:[email protected];tag=5458100f2dc44fdcb065314900298768
To: sip:[email protected]
Call-ID: 2b4f54b175bd4c4ebdde62d8847553c7
CSeq: 28990 REGISTER
User-Agent: MicroSIP/3.18.2
Contact: sip:[email protected]:55245;ob
Expires: 0
Authorization: Digest username="7385", realm="sip.example.net.au", nonce="WxTacFsU2USCyjLoANeeeoVhbKEUpMQs", uri="sip:192.168.44.3", response="6cc3f02a9a62f8647eaa79dbbc
dc4d89"
Content-Length: 0

04 Jun 06:16:36.398/GLOBAL/b2bua: SENDING message to sip.example.net.au:5060:
REGISTER sip:192.168.44.3 SIP/2.0
Via: SIP/2.0/UDP 192.168.44.3:5060;branch=z9hG4bKf05857b0f7d8d29cce0b4981cfaeff7d;rport
Via: SIP/2.0/UDP 192.168.44.1:55245;branch=z9hG4bKPj425267067e5f437ca66867b560c7efba;rport=55245
Route: sip:192.168.44.3;lr
Max-Forwards: 70
From: sip:[email protected];tag=5458100f2dc44fdcb065314900298768
To: sip:[email protected]
Call-ID: 2b4f54b175bd4c4ebdde62d8847553c7
CSeq: 28990 REGISTER
User-Agent: MicroSIP/3.18.2
Contact: sip:[email protected]:55245;ob
Expires: 0
Authorization: Digest username="7385", realm="sip.example.net.au", nonce="WxTacFsU2USCyjLoANeeeoVhbKEUpMQs", uri="sip:192.168.44.3", response="6cc3f02a9a62f8647eaa79dbbc
dc4d89"
Content-Length: 0

04 Jun 06:16:36.410/GLOBAL/b2bua: RECEIVED message from 1.2.3.4:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.44.3:5060;received=203.55.174.123;branch=z9hG4bKf05857b0f7d8d29cce0b4981cfaeff7d;rport=63230
Via: SIP/2.0/UDP 192.168.44.1:55245;branch=z9hG4bKPj425267067e5f437ca66867b560c7efba;rport=55245
From: sip:[email protected];tag=5458100f2dc44fdcb065314900298768
To: sip:[email protected];tag=290f473369cc3c154b744fae3269e66d.b590
Call-ID: 2b4f54b175bd4c4ebdde62d8847553c7
CSeq: 28990 REGISTER
User-Agent: example-Registrar
Content-Length: 0

04 Jun 06:16:36.419/GLOBAL/b2bua: SENDING message to 192.168.44.1:55245:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.44.1:55245;rport=55245;branch=z9hG4bKPj425267067e5f437ca66867b560c7efba
From: sip:[email protected];tag=5458100f2dc44fdcb065314900298768
To: sip:[email protected];tag=290f473369cc3c154b744fae3269e66d.b590
Call-ID: 2b4f54b175bd4c4ebdde62d8847553c7
CSeq: 28990 REGISTER
User-Agent: example-Registrar
Content-Length: 0

04 Jun 06:16:39.544/GLOBAL/b2bua: RECEIVED message from 192.168.44.1:55245:
REGISTER sip:192.168.44.3 SIP/2.0
Via: SIP/2.0/UDP 192.168.44.1:55245;rport;branch=z9hG4bKPjfb7460593f7c45d598c42d2074a0f9b3
Route: sip:192.168.44.3;lr
Max-Forwards: 70
From: sip:[email protected];tag=9dac76b5f7da472d92012e31bebf2f8d
To: sip:[email protected]
Call-ID: 3803c3ce93cc4fccac17f3369eb05984
CSeq: 27006 REGISTER
User-Agent: MicroSIP/3.18.2
Contact: sip:[email protected]:55245;ob
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length: 0

REGISTER sip:192.168.44.3 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK400626d679516986c7c9c675e171be5e;rport
Via: SIP/2.0/UDP 192.168.44.1:55245;branch=z9hG4bKPjfb7460593f7c45d598c42d2074a0f9b3;rport=55245
Route: sip:192.168.44.3;lr
Max-Forwards: 70
From: sip:[email protected];tag=9dac76b5f7da472d92012e31bebf2f8d
To: sip:[email protected]
Call-ID: 3803c3ce93cc4fccac17f3369eb05984
CSeq: 27006 REGISTER
User-Agent: MicroSIP/3.18.2
Contact: sip:[email protected]:55245;ob
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length: 0

04 Jun 06:16:39.546/GLOBAL/b2bua: SENDING message to sip.example.net.au:5060:
REGISTER sip:192.168.44.3 SIP/2.0
Via: SIP/2.0/UDP 192.168.44.3:5060;branch=z9hG4bK400626d679516986c7c9c675e171be5e;rport
Via: SIP/2.0/UDP 192.168.44.1:55245;branch=z9hG4bKPjfb7460593f7c45d598c42d2074a0f9b3;rport=55245
Route: sip:192.168.44.3;lr
Max-Forwards: 70
From: sip:[email protected];tag=9dac76b5f7da472d92012e31bebf2f8d
To: sip:[email protected]
Call-ID: 3803c3ce93cc4fccac17f3369eb05984
CSeq: 27006 REGISTER
User-Agent: MicroSIP/3.18.2
Contact: sip:[email protected]:55245;ob
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length: 0

04 Jun 06:16:39.549/GLOBAL/b2bua: RECEIVED message from 103.26.174.4:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.44.3:5060;branch=z9hG4bK400626d679516986c7c9c675e171be5e;rport=63230;received=203.55.174.123
Via: SIP/2.0/UDP 192.168.44.1:55245;branch=z9hG4bKPjfb7460593f7c45d598c42d2074a0f9b3;rport=55245
From: sip:[email protected];tag=9dac76b5f7da472d92012e31bebf2f8d
To: sip:[email protected];tag=b27e1a1d33761e85846fc98f5f3a7e58.9813
Call-ID: 3803c3ce93cc4fccac17f3369eb05984
CSeq: 27006 REGISTER
WWW-Authenticate: Digest realm="sip.example.net.au", nonce="WxTac1sU2Uc6VhynGRfYBXUahzmR1xhY"
User-Agent: example-LB
Content-Length: 0

04 Jun 06:16:39.557/GLOBAL/b2bua: SENDING message to 192.168.44.1:55245:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.44.1:55245;rport=55245;branch=z9hG4bKPjfb7460593f7c45d598c42d2074a0f9b3
From: sip:[email protected];tag=9dac76b5f7da472d92012e31bebf2f8d
To: sip:[email protected];tag=b27e1a1d33761e85846fc98f5f3a7e58.9813
Call-ID: 3803c3ce93cc4fccac17f3369eb05984
CSeq: 27006 REGISTER
WWW-Authenticate: Digest realm="sip.example.net.au", nonce="WxTac1sU2Uc6VhynGRfYBXUahzmR1xhY"
User-Agent: example-LB
Content-Length: 0

04 Jun 06:16:39.558/GLOBAL/b2bua: RECEIVED message from 192.168.44.1:55245:
REGISTER sip:192.168.44.3 SIP/2.0
Via: SIP/2.0/UDP 192.168.44.1:55245;rport;branch=z9hG4bKPj7b2c654661d64ddfb76cf3d38c141065
Route: sip:192.168.44.3;lr
Max-Forwards: 70
From: sip:[email protected];tag=9dac76b5f7da472d92012e31bebf2f8d
To: sip:[email protected]
Call-ID: 3803c3ce93cc4fccac17f3369eb05984
CSeq: 27007 REGISTER
User-Agent: MicroSIP/3.18.2
Contact: sip:[email protected]:55245;ob
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Authorization: Digest username="7385", realm="sip.example.net.au", nonce="WxTac1sU2Uc6VhynGRfYBXUahzmR1xhY", uri="sip:192.168.44.3", response="5553b819c94df53a65f1a3e887
6d6168"
Content-Length: 0

REGISTER sip:192.168.44.3 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK89a0fe9928c4e9fab00f2ec7d98e4a01;rport
Via: SIP/2.0/UDP 192.168.44.1:55245;branch=z9hG4bKPj7b2c654661d64ddfb76cf3d38c141065;rport=55245
Route: sip:192.168.44.3;lr
Max-Forwards: 70
From: sip:[email protected];tag=9dac76b5f7da472d92012e31bebf2f8d
To: sip:[email protected]
Call-ID: 3803c3ce93cc4fccac17f3369eb05984
CSeq: 27007 REGISTER
User-Agent: MicroSIP/3.18.2
Contact: sip:[email protected]:55245;ob
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Authorization: Digest username="7385", realm="sip.example.net.au", nonce="WxTac1sU2Uc6VhynGRfYBXUahzmR1xhY", uri="sip:192.168.44.3", response="5553b819c94df53a65f1a3e887
6d6168"
Content-Length: 0

04 Jun 06:16:39.568/GLOBAL/b2bua: SENDING message to sip.example.net.au:5060:
REGISTER sip:192.168.44.3 SIP/2.0
Via: SIP/2.0/UDP 192.168.44.3:5060;branch=z9hG4bK89a0fe9928c4e9fab00f2ec7d98e4a01;rport
Via: SIP/2.0/UDP 192.168.44.1:55245;branch=z9hG4bKPj7b2c654661d64ddfb76cf3d38c141065;rport=55245
Route: sip:192.168.44.3;lr
Max-Forwards: 70
From: sip:[email protected];tag=9dac76b5f7da472d92012e31bebf2f8d
To: sip:[email protected]
Call-ID: 3803c3ce93cc4fccac17f3369eb05984
CSeq: 27007 REGISTER
User-Agent: MicroSIP/3.18.2
Contact: sip:[email protected]:55245;ob
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Authorization: Digest username="7385", realm="sip.example.net.au", nonce="WxTac1sU2Uc6VhynGRfYBXUahzmR1xhY", uri="sip:192.168.44.3", response="5553b819c94df53a65f1a3e887
6d6168"
Content-Length: 0

04 Jun 06:16:39.589/GLOBAL/b2bua: RECEIVED message from 103.26.174.36:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.44.3:5060;received=203.55.174.123;branch=z9hG4bK89a0fe9928c4e9fab00f2ec7d98e4a01;rport=63230
Via: SIP/2.0/UDP 192.168.44.1:55245;branch=z9hG4bKPj7b2c654661d64ddfb76cf3d38c141065;rport=55245
From: sip:[email protected];tag=9dac76b5f7da472d92012e31bebf2f8d
To: sip:[email protected];tag=38a879c93a4c4105a45c2bf6407aed55.9192
Call-ID: 3803c3ce93cc4fccac17f3369eb05984
CSeq: 27007 REGISTER
Contact: sip:[email protected]:55245;ob;received="sip:203.55.174.123:63230";expires=300
User-Agent: example-Registrar
Content-Length: 0

04 Jun 06:16:39.598/GLOBAL/b2bua: SENDING message to 192.168.44.1:55245:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.44.1:55245;rport=55245;branch=z9hG4bKPj7b2c654661d64ddfb76cf3d38c141065
From: sip:[email protected];tag=9dac76b5f7da472d92012e31bebf2f8d
To: sip:[email protected];tag=38a879c93a4c4105a45c2bf6407aed55.9192
Call-ID: 3803c3ce93cc4fccac17f3369eb05984
CSeq: 27007 REGISTER
Contact: sip:[email protected]:55245;ob;received="sip:203.55.174.123:63230";expires=300
User-Agent: example-Registrar
Content-Length: 0

04 Jun 06:16:53.769/GLOBAL/b2bua: RECEIVED message from 192.168.44.1:55245:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.44.1:55245;rport;branch=z9hG4bKPj39262faf126e4dcba1d898a0e561bdd1
Max-Forwards: 70
From: sip:[email protected];tag=d37cfda85b554070869b0285abb41685
To: sip:[email protected]
Contact: sip:[email protected]:55245;ob
Call-ID: f588507ff3c64fc5bed33710e960410d
CSeq: 26283 INVITE
Route: sip:192.168.44.3;lr
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: MicroSIP/3.18.2
Content-Type: application/sdp
Content-Length: 340

v=0
o=- 3737117813 3737117813 IN IP4 192.168.44.1
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 8 0 101
c=IN IP4 192.168.44.1
b=TIAS:64000
a=rtcp:4001 IN IP4 192.168.44.1
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ssrc:1495688157 cname:192b28e72d4a16ce

04 Jun 06:16:53.779/GLOBAL/b2bua: SENDING message to 192.168.44.1:55245:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.44.1:55245;rport=55245;branch=z9hG4bKPj39262faf126e4dcba1d898a0e561bdd1
From: sip:[email protected];tag=d37cfda85b554070869b0285abb41685
To: sip:[email protected]
Call-ID: f588507ff3c64fc5bed33710e960410d
CSeq: 26283 INVITE
Content-Length: 0

2018-06-04 06:16:53.779857 Udp_server: unhandled exception when processing incoming data

Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/sippy/Udp_server.py", line 252, in handle_read
self.uopts.data_callback(data, address, self, rtime)
File "/usr/lib/python2.7/site-packages/sippy/SipTransactionManager.py", line 330, in handleIncoming
self.incomingRequest(req, checksum, tids, server)
File "/usr/lib/python2.7/site-packages/sippy/SipTransactionManager.py", line 616, in incomingRequest
rval = self.req_cb(msg, t)
File "/usr/lib/python2.7/site-packages/sippy/b2bua_simple.py", line 87, in recvRequest
return cc.uaA.recvRequest(req, sip_t)
File "/usr/lib/python2.7/site-packages/sippy/UA.py", line 171, in recvRequest
self.emitPendingEvents()
File "/usr/lib/python2.7/site-packages/sippy/UA.py", line 267, in emitPendingEvents
self.event_cb(event, self)
File "/usr/lib/python2.7/site-packages/sippy/b2bua_simple.py", line 62, in recvEvent
self.uaO.recvEvent(event)
File "/usr/lib/python2.7/site-packages/sippy/UA.py", line 217, in recvEvent
newstate = self.state.recvEvent(event)
File "/usr/lib/python2.7/site-packages/sippy/UacStateIdle.py", line 80, in recvEvent
laddress = self.ua.source_address, cb_ifver = 2, compact = self.ua.compact_sip)
File "/usr/lib/python2.7/site-packages/sippy/SipTransactionManager.py", line 354, in newTransaction
t.data = msg.localStr(*t.userv.uopts.getSIPaddr(), compact = t.compact)
File "/usr/lib/python2.7/site-packages/sippy/SipMsg.py", line 169, in localStr
mbody = self.body.localStr(local_addr, local_port)
File "/usr/lib/python2.7/site-packages/sippy/MsgBody.py", line 62, in localStr
return self.content.localStr(local_addr, local_port)
AttributeError: 'unicode' object has no attribute 'localStr'

04 Jun 06:17:27.821/GLOBAL/b2bua: RECEIVED message from 192.168.44.1:55245:
CANCEL sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.44.1:55245;rport;branch=z9hG4bKPj39262faf126e4dcba1d898a0e561bdd1
Max-Forwards: 70
From: sip:[email protected];tag=d37cfda85b554070869b0285abb41685
To: sip:[email protected]
Call-ID: f588507ff3c64fc5bed33710e960410d
CSeq: 26283 CANCEL
Route: sip:192.168.44.3;lr
Content-Length: 0

04 Jun 06:17:27.830/GLOBAL/b2bua: SENDING message to 192.168.44.1:55245:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.44.1:55245;rport=55245;branch=z9hG4bKPj39262faf126e4dcba1d898a0e561bdd1
From: sip:[email protected];tag=d37cfda85b554070869b0285abb41685
To: sip:[email protected]
Call-ID: f588507ff3c64fc5bed33710e960410d
CSeq: 26283 CANCEL
Content-Length: 0

04 Jun 06:17:27.830/GLOBAL/b2bua: SENDING message to 192.168.44.1:55245:
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 192.168.44.1:55245;rport=55245;branch=z9hG4bKPj39262faf126e4dcba1d898a0e561bdd1
From: sip:[email protected];tag=d37cfda85b554070869b0285abb41685
To: sip:[email protected];tag=45313239068d7168de0659f93f0137c1
Call-ID: f588507ff3c64fc5bed33710e960410d
CSeq: 26283 INVITE
Content-Length: 0

04 Jun 06:17:27.831/GLOBAL/b2bua: RECEIVED message from 192.168.44.1:55245:
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.44.1:55245;rport;branch=z9hG4bKPj39262faf126e4dcba1d898a0e561bdd1
Max-Forwards: 70
From: sip:[email protected];tag=d37cfda85b554070869b0285abb41685
To: sip:[email protected];tag=45313239068d7168de0659f93f0137c1
Call-ID: f588507ff3c64fc5bed33710e960410d
CSeq: 26283 ACK
Route: sip:192.168.44.3;lr
Content-Length: 0

`

Test scheme:
ua1 ([email protected]) -> b2bua (192.168.0.101) -> ua2 ([email protected])
Media is passed through an rtpproxy (192.168.0.101).

As shown below, RTCP SDP attribute pass from ingress call leg to egress call leg unmodified,
although media is passed through an rtpproxy.
I think, that the RTCP SDP attribute should be removed from egress call leg.

Ingress INVITE:

Request-Line: INVITE sip:[email protected]:5062 SIP/2.0
Message Header
    Via: SIP/2.0/UDP 192.168.0.134:1534;rport;branch=z9hG4bKPj735a2264cba84c36bd9657602265d463
    Max-Forwards: 70
    From: <sip:[email protected]>;tag=7da4ba7ff67a422bb089465bbcd2bf65
    To: <sip:[email protected]>
    Contact: <sip:[email protected]:1534;ob>
    Call-ID: 68504c1dfbeb42dca549be075abaa71a
    CSeq: 19945 INVITE
    Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
    Supported: replaces, 100rel, timer, norefersub
    Session-Expires: 1800
    Min-SE: 90
    User-Agent: MicroSIP/3.18.3
    Content-Type: application/sdp
    Content-Length:   319
Message Body
    Session Description Protocol
        Session Description Protocol Version (v): 0
        Owner/Creator, Session Id (o): - 3731448157 3731448157 IN IP4 192.168.0.134
        Session Name (s): pjmedia
        Bandwidth Information (b): AS:84
        Time Description, active time (t): 0 0
        Session Attribute (a): X-nat:0
        Media Description, name and address (m): audio 4004 RTP/AVP 8 101
        Connection Information (c): IN IP4 192.168.0.134
        Bandwidth Information (b): TIAS:64000
        Media Attribute (a): rtcp:4005 IN IP4 192.168.0.134
        Media Attribute (a): sendrecv
        Media Attribute (a): rtpmap:8 PCMA/8000
        Media Attribute (a): rtpmap:101 telephone-event/8000
        Media Attribute (a): fmtp:101 0-16
        Media Attribute (a): ssrc:2129558419 cname:63600a3a52cb6dee

Egress INVITE:

Request-Line: INVITE sip:[email protected]:58604 SIP/2.0
Message Header
    Via: SIP/2.0/UDP 192.168.0.101:5062;branch=z9hG4bKa83470d3fd30bffb418e9933f7bab4c7;rport
    Max-Forwards: 69
    From: <sip:[email protected]>;tag=8636a93c89e788e511537c4aea1c458f
    To: <sip:[email protected]>
    Call-ID: 68504c1dfbeb42dca549be075abaa71a-b2b_1
    CSeq: 200 INVITE
    Contact: <sip:[email protected]:5062>
    Expires: 300
    User-Agent: Sippy B2BUA (RADIUS)
    cisco-GUID: 3401962361-1366442318-3627064869-582878196
    h323-conf-id: 3401962361-1366442318-3627064869-582878196
    Content-Type: application/sdp
    Content-Length: 344
Message Body
    Session Description Protocol
        Session Description Protocol Version (v): 0
        Owner/Creator, Session Id (o): - 1035059087891 1035059087891 IN IP4 192.168.0.101
        Session Name (s): pjmedia
        Connection Information (c): IN IP4 192.168.0.101
        Bandwidth Information (b): AS:84
        Time Description, active time (t): 0 0
        Session Attribute (a): X-nat:0
        Media Description, name and address (m): audio 41808 RTP/AVP 8 101
        Bandwidth Information (b): TIAS:64000
        Media Attribute (a): rtcp:4005 IN IP4 192.168.0.134
        Media Attribute (a): sendrecv
        Media Attribute (a): rtpmap:8 PCMA/8000
        Media Attribute (a): rtpmap:101 telephone-event/8000
        Media Attribute (a): fmtp:101 0-16
        Media Attribute (a): ssrc:2129558419 cname:63600a3a52cb6dee
        Media Attribute (a): nortpproxy:yes

I'm not sure what's the expected behavior of a B2BUA, I added this change but it is specific to my use case, can it be generalized and added to upstream?

I don't know how to use it.

Hi

For operation as proper B2BUA the CallID needs to be different on both legs. This is especially true to make spiraling calls working with Kamailio as a proxy.

It looks like the radius variant has some support for it, but this is not implemented on the simple version.

-Benoit-

Hi

When acting as a B2BUA for example between a kamailio routing core and a kamailio registrar node usually informations are passed to the registrar as custom sip headers. Like X-VM: yes to tell the registrar that the customer has voicemail enabled so the registrar can forward the call to voicemail if needed.

So it would be very handy to have sippy pass on all 'unknown' header as is. Or at least to be able to define some regex matcht header like X-.* which would be passed transparently on the 2nd leg.

-Benoit-

Debian 8.1 Jessie, after fresh install using method from docs:

pip install git+https://github.com/sippy/b2bua

When executing:

b2bua_simple -f -n myipaddress

I get the following error:

2015-10-11 15:47:49.134474 Udp_server: unhandled exception when processing incoming data

Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/sippy/Udp_server.py", line 228, in handle_read
self.uopts.data_callback(data, address, self, rtime)
File "/usr/local/lib/python2.7/dist-packages/sippy/SipTransactionManager.py", line 326, in handleIncoming
self.incomingRequest(req, checksum, tids, server)
File "/usr/local/lib/python2.7/dist-packages/sippy/SipTransactionManager.py", line 584, in incomingRequest
t.userv = self.l4r.getServer(msg.getSource())
File "/usr/local/lib/python2.7/dist-packages/sippy/SipTransactionManager.py", line 170, in getServer
return self.cache_l2s[laddress]
KeyError: ('myipaddress', <sippy.SipConf.MyPort object at 0x7f83284f0550>)

What should I fix?

Dear team,
I am currently trying to test this project with FreeRadius - Custom Modules for AAA.
In the first test I am getting the following issues:

Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib64/python2.7/threading.py", line 812, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/site-packages/sippy/External_command.py", line 74, in run
pipe.stdin.writelines(batch)
IOError: [Errno 32] Broken pipe

Is this something related to the B2BUA ?

Regards,

Hi @sobomax,

I wanted to add the sip realm in the authentication radius request (without perform digest authentication), and I've been looking through RadiusAuthorization; there is an extra_attributes parameter in the do_auth method which is not used anywhere and got me thinking.

Similarly to pass_headers parameters it would be nice to have an option to define a sip header from which b2bua will get specific radius attributes and add them to the Authentication request (via the extra_attributes property)

So I've modified the b2bua a bit to support exactly that. The patch adds an -x option, from which the user can add a sip header for b2bua to read radius attributes.

So for example, opensips might do something like:

append_hf('X-Test-Header: h323-ivr-out=SomeProperty=1\r\n');
$du = 'b2bua.ip'

route(RELAY);

sippy would have to run with -x x-test-header parameter and in the authentication request the header contents is added to the radius request. Obviously it's up to the administrator/ matching dictionary to supply valid radius key/ value pairs for this to work.

I am providing the patch in this comment, I don't know if you would be willing to add it to the b2bua source code. If you are, I'd be happy to supply you with a PR

Index: sippy/b2bua_radius.py
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- sippy/b2bua_radius.py	(revision f1c375b3454445b66b88c4b3cdc365306bb0ef18)
+++ sippy/b2bua_radius.py	(date 1603809097780)
@@ -119,11 +119,12 @@
     rtp_proxy_session = None
     huntstop_scodes = None
     pass_headers = None
+    extra_attributes = None
     auth_proc = None
     proxied = False
     challenge = None
 
-    def __init__(self, remote_ip, source, global_config, pass_headers):
+    def __init__(self, remote_ip, source, global_config, pass_headers, extra_attributes):
         self.id = CallController.id
         CallController.id += 1
         self.global_config = global_config
@@ -137,6 +138,7 @@
         self.remote_ip = remote_ip
         self.source = source
         self.pass_headers = pass_headers
+        self.extra_attributes = extra_attributes
 
     def recvEvent(self, event, ua):
         if ua == self.uaA:
@@ -191,11 +193,12 @@
                 elif auth == None or auth.username == None or len(auth.username) == 0:
                     self.username = self.remote_ip
                     self.auth_proc = self.global_config['_radius_client'].do_auth(self.remote_ip, self.cli, self.cld, self.cGUID, \
-                      self.cId, self.remote_ip, self.rDone)
+                      self.cId, self.remote_ip, self.rDone, extra_attributes=self.extra_attributes)
                 else:
                     self.username = auth.username
                     self.auth_proc = self.global_config['_radius_client'].do_auth(auth.username, self.cli, self.cld, self.cGUID, 
-                      self.cId, self.remote_ip, self.rDone, auth.realm, auth.nonce, auth.uri, auth.response)
+                      self.cId, self.remote_ip, self.rDone, auth.realm, auth.nonce, auth.uri, auth.response,
+                      extra_attributes=self.extra_attributes)
                 return
             if self.state not in (CCStateARComplete, CCStateConnected, CCStateDisconnecting) or self.uaO == None:
                 return
@@ -465,7 +468,27 @@
                 hfs = req.getHFs(header)
                 if len(hfs) > 0:
                     pass_headers.extend(hfs)
-            cc = CallController(remote_ip, source, self.global_config, pass_headers)
+
+            extra_attributes = None
+
+            if 'auth_extra_header' in self.global_config:
+                header = self.global_config['auth_extra_header']
+
+                hfs = req.getHFs(header)
+
+                if len(hfs) > 0:
+                    extra_attributes = []
+
+                    for header in hfs:
+                        kvPairs = header.body.body.split(';')
+
+                        for pair in kvPairs:
+                            [key, _, value] = pair.partition("=")
+
+                            if value != '':
+                                extra_attributes.append((key, value))
+
+            cc = CallController(remote_ip, source, self.global_config, pass_headers, extra_attributes)
             cc.challenge = challenge
             rval = cc.uaA.recvRequest(req, sip_t)
             self.ccmap.append(cc)
@@ -668,7 +691,7 @@
     global_config['_orig_argv'] = sys.argv[:]
     global_config['_orig_cwd'] = os.getcwd()
     try:
-        opts, args = getopt.getopt(sys.argv[1:], 'fDl:p:d:P:L:s:a:t:T:k:m:A:ur:F:R:h:c:M:HC:W:',
+        opts, args = getopt.getopt(sys.argv[1:], 'fDl:p:d:P:L:s:a:t:T:k:m:A:ur:F:R:h:c:M:HC:W:x:',
           global_config.get_longopts())
     except getopt.GetoptError:
         usage(global_config)
@@ -759,6 +782,9 @@
         if o == '-h':
             for a in a.split(','):
                 global_config.check_and_set('pass_header', a)
+            continue
+        if o == '-x':
+            global_config.check_and_set('auth_extra_header', a)
             continue
         if o == '-c':
             global_config.check_and_set('b2bua_socket', a)
Index: sippy/MyConfigParser.py
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- sippy/MyConfigParser.py	(revision f1c375b3454445b66b88c4b3cdc365306bb0ef18)
+++ sippy/MyConfigParser.py	(date 1603808883519)
@@ -98,6 +98,8 @@
                              'and "SUBSCRIBE" messages. Address in the format ' \
                              '"host[:port]"'),
  'nat_traversal':     ('B', 'enable NAT traversal for signalling'), \
+ 'auth_extra_header': ('S', 'sip header containing radius parameters to pass ' \
+                            'to authentication request'), \
  'xmpp_b2bua_id':     ('I', 'ID passed to the XMPP socket server')}
 
 class MyConfigParser(RawConfigParser):

I've been trying to use sippy with radius support but I am facing an issue with MonoTime implementation.

It seems that if a route returned from radius which contains credit-time, expires and np_expires parameters those are being cast as ints and when passed to a MonoAbsTimeout object, b2bua throws an exception that mtime is not MonoTime. I am guessing similar issues might exist with max_credit_time and similar global variables.

I've thought of doing something simple like

if isinstance(mtime, float):
    mtime = (MonoTime()) + mtime

but it didn't work. I'm trying to resolve this myself, but I haven't yet understood the source code with regards to Time objects and any help would be greatly appreciated.

@sobomax Thank you for the work you've done on Sippy!

Hi

Kamailio checks if a dispatcher is reachable and alive by sending OPTIONS

At the moment, b2bua replies with 501 not implemented which causes kamailio to consider the dispatcher being down.

I just changed one line to make this work:

        if req.getMethod() in ('NOTIFY', 'PING', 'OPTIONS'):
            # Whynot?
            return (req.genResponse(200, 'OK'), None, None)

I'm not sure if PING is a valid SIP method. Maybe this should be OPTIONS?

Also I suspect, this would just reply with 200 OK to notify. But CPE needs to get NOTIFY messages for MWI as example.

-Benoît-

Trying to replace rtpproxy with more modern sipwise/rtpengine

According to their documentation:
rtpengine can be used as a drop-in replacement for any other compatible RTP proxy

But it seems that Sippy is sending some commands, that are not understood by rtpengine

Any fixes possible? Or maybe suggestions how to get b2bua working with rtpengine?

radiusclient-ng has been merged into the freeradius project. Gut the dependency on the former in favor of the latter.

Do you intend to have TLS support ?

First off let me say thanks for the work you've done on b2bua.

I'm trying to configure b2bua to work with freeradius-client but it seems that I've hit a wall with regards the dictionary attributes being used. I've installed b2bua by doing pip install git+https://github.com/sippy/b2bua as documents mentioned.

I've added the dictionary file from the sippy distribution to radiusclient.conf and made a test call to the b2bua. The logs mention the following:

User-Name                        = '10.10.10.1'
Password                         = 'cisco'
Calling-Station-Id               = 'test'
Called-Station-Id                = '123'
h323-conf-id                     = '53B0C08A 1DEBA549 90D7CA3C 4944C22F'
call-id                          = 'bbnhreG4Sj8VdLEDovHXE5JGExu2i6iE'
h323-remote-address              = '10.10.10.1'
h323-session-protocol            = 'sipv2'

However on freeradius the request appears as:

(9)   Attr-26 = 0x616e696d010c31302e31302e31302e31
(9)   User-Password = "cisco"
(9)   Attr-26 = 0x530909651f0674657374
(9)   Attr-26 = 0x6f542d741e05313233
(9)   Attr-26 = 0x0a3709091832683332332d636f6e662d69643d3533423043303841203144454241353439203930443743413343203439343443323246
(9)   Attr-26 = 0x46090945012a63616c6c2d69643d62626e6872654734536a3856644c45446f76485845354a474578753269366945
(9)   Attr-26 = 0x6f63614a1720683332332d72656d6f74652d616464726573733d31302e31302e31302e31
(9)   Attr-26 = 0x2e580909011d683332332d73657373696f6e2d70726f746f636f6c3d7369707632
(9)   NAS-Port = 5060
(9)   NAS-IP-Address = 10.10.10.5

As you can see everything comes across as attribute 26. I've taken a trace using tcpdump and indeed everything is attribute 26:

I've tried adding the b2bua's dictionary to freeradius, and everything falls under "Vendor-Specific" (which makes sense since it's attribute is 26) but they come across corrupted.

Could someone please help me out on what I am doing wrong?