PJSIP Ports, Multiple IP Addresses And Wrong Owner
Dear list,
I am currently trying to send faxes via T.38 using PJSIP (newest version 2.3) with Asterisk 13.0.2. After having configured PJSIP, I have seen several things the cause of which I would like to know.
1) Ports and IP addresses which PJSIP bind to
I have configured one transport like that:
[tr_wZCMk5MvC2ATNzAr]
type = transport protocol = udp bind = 192.168.20.48
Nevertheless, PJSIP binds to more ports and IP addresses than expected:
root@spock:~# netstat -apnv | grep asterisk udp 0 0 192.168.20.48:5060 0.0.0.0:* 21416/asterisk
udp 0 0 0.0.0.0:42415 0.0.0.0:* 21416/asterisk
udp 0 0 0.0.0.0:48565 0.0.0.0:* 21416/asterisk
[SNIP]
This is on a box which has one physical NIC which has configured multiple IP addresses by ethernet aliasing:
eth0 Link encap:Ethernet HWaddr 02:01:01:01:05:01
inet addr:192.168.20.238 Bcast:192.168.20.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:32321283 errors:0 dropped:0 overruns:0 frame:0
TX packets:171282095 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9690993944 (9.0 GiB) TX bytes:244294378305 (227.5 GiB)
eth0:1 Link encap:Ethernet HWaddr 02:01:01:01:05:01
inet addr:192.168.20.48 Bcast:192.168.20.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
[and so on, 10 IP addresses]
So what is the meaning of the additional ports PJSIP is opening, and why does it open these on all IP addresses?
By the way, I already have tried to make sure that it’s really PJSIP which opens these. After all, I can tell for sure that they are NOT opened if I use chan_sip instead of PJSIP with an otherwise identical software version (I am compiling myself so I was able to produce two flavors of Asterisk which are identical except that one uses chan_sip, the other one chan_pjsip). I furthermore have compiled an additional Asterisk / PJSIP flavor with as few modules, channels etc. as possible, but this flavor still opens the additional ports.
2) Wrong owner in SDP (o= line)
I think this problem relates to the first one.
I am currently unable to send a fax, and I suspect this is due to the fact that Asterisk / PJSIP produces a wrong owner record. A typical INVITE:
No. Time Source Destination Protocol Length Info
9225 7.503015 192.168.20.48 xx.xxx.xx.xxx SIP/SDP 886 Request: INVITE sip:004982349663847@fpbx.de |
Frame 9225: 886 bytes on wire (7088 bits), 886 bytes captured (7088 bits)
Ethernet II, Src: MS-NLB-PhysServer-01_01:01:05:01 (02:01:01:01:05:01), Dst: D-Link_03:a4:18 (00:1b:11:03:a4:18)
Internet Protocol Version 4, Src: 192.168.20.48 (192.168.20.48), Dst: xx.xxx.xx.xxx (xx.xxx.xx.xxx)
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060)
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:00498234xxxxxxx@itsp.de SIP/2.0
Method: INVITE
Request-URI: sip:00498234xxxxxxx@itsp.de
Request-URI User Part: 0049823xxxxxxx
Request-URI Host Part: itsp.de
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 79.211.71.113:5060;rport;branch=z9hG4bKPj7afca7e1-0c3b-494f-978a-844fa19cfc4a
Transport: UDP
Sent-by Address: yy.yyy.yy.yyy
Sent-by port: 5060
RPort: rport
Branch: z9hG4bKPj7afca7e1-0c3b-494f-978a-844fa19cfc4a
From:
SIP from address: sip:username@itsp.de
SIP from address User Part: username
SIP from address Host Part: itsp.de
SIP from tag: 4e855dd1-4a8c-41a9-9524-038d32c08ce3
To:
SIP to address: sip:00498234xxxxxxx@itsp.de
SIP to address User Part: 00498234xxxxxxx
SIP to address Host Part: itsp.de
Contact:
Contact URI: sip:username@yy.yyy.yy.yyy
Contact URI User Part: username
Contact URI Host Part: yy.yyy.yy.yyy
Call-ID: ad46d131-91ab-44bd-8b7e-40551b7fd8e5
CSeq: 20417 INVITE
Sequence Number: 20417
Method: INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Content-Type: application/sdp
Content-Length: 238
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): – 928891384 928891384 IN IP4 192.168.20.238
Owner Username: –
Session ID: 928891384
Session Version: 928891384
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 192.168.20.238
Session Name (s): Asterisk
Connection Information (c): IN IP4 yy.yyy.yy.yyy
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: yy.yyy.yy.yyy
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 11544 RTP/AVP 0 101
Media Type: audio
Media Port: 11544
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMU
Media Format: DynamicRTP-Type-101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute Fieldname: rtpmap
Media Format: 0
MIME Type: PCMU
Sample Rate: 8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
Media Attribute (a): ptime:20
Media Attribute Fieldname: ptime
Media Attribute Value: 20
Media Attribute (a): maxptime:150
Media Attribute Fieldname: maxptime
Media Attribute Value: 150
Media Attribute (a): sendrecv
Note that in the SDP part it claims the Owner/Creator (o=) to be 192.168.20.238 which is the main IP address of the box (eth0), but not the one where Asterisk / PJSIP should bind to.
So, I’ve got two questions here: First, how do I tell Asterisk / PJSIP which IP address it should use as the owner (o=) IP address (I didn’t see anything in the docs which would allow for that), and secondly, could a wrong owner be the reason for the ITSP to hang up immediately after the T.38 re-invite? In other words, does a wrong owner harm at all?
Thank you very much for any ideas,
Recursive
3 thoughts on - PJSIP Ports, Multiple IP Addresses And Wrong Owner
Using an extremely simple module.conf:
autoload = no load => pbx_config.so load => res_sorcery_config.so load => res_sorcery_memory.so load => res_sorcery_astdb.so load => chan_pjsip.so load => res_pjsip.so load => res_pjsip_session.so load => res_pjsip_sdp_rtp.so load => res_pjsip_t38.so load => res_rtp_asterisk.so
With a single UDP bind-all transport defined in pjsip.conf, I get the following:
udp 0 0 0.0.0.0:52678 0.0.0.0:*
3797/asterisk udp 0 0 0.0.0.0:5060 0.0.0.0:*
3797/asterisk
Removing the PJSIP modules does cause the other bindaddr to disappear.
Interesting.
Without a lot more investigation, I’m not sure where that one is coming from. I’ll reply back here when I’ve had a chance to look deeper.
First, it would be good to confirm with your provider that the owner line is actually the problem. Making arbitrary code changes based on guesses is never a good idea! 🙂
The IP address in the SDP owner line will be one of the following:
(1) The same information from the SDP connection line if possible. Note that this is applied prior to NAT changes, which may be why the IP address in the owner line differs from the connection IP addresses.
(2) The configured media address, if present
(3) The IP address of ourself, which is obtained via a system call
This does not apply to a particular signalling transport, since the transport used for signalling does not necessarily equate to the transport information used for media.
From what I can tell in your trace, the only aspect here that may be incorrect is not applying the NAT’d IP address to the owner information. That is, in an ideal world, the owner information would match the IP address provided in the connection lines. Per RFC 4566, section 5.2, we shouldn’t be sending a local IP address in the owner information, and it looks like we’re still doing that here.
Again, however, it’d be good to know that this is actually causing a problem before making an issue. Generally, most implementations don’t assign semantic meaning to the IP address in the owner line, as the purpose of the owner field is to construct a globally unique identifier for the session, not to determine where to send media to. In fact, it is permissible in some situations to provide obfuscated IP
addresses in the owner field. Again, from RFC 4566 section 5.2:
{quote}
In general, the “o=” field serves as a globally unique identifier for
this version of this session description, and the subfields excepting
the version taken together identify the session irrespective of any
modifications.
For privacy reasons, it is sometimes desirable to obfuscate the and private MAY be
username and IP address of the session originator. If this is a
concern, an arbitrary
chosen to populate the “o=” field, provided that these are selected
in a manner that does not affect the global uniqueness of the field.
{quote}
You’ll need to confirm this with your provider. If they are assigning semantic meaning beyond constructing a globally unique identifier to the IP address in the owner field, then they are taking a rather extreme view of the RFC.
Matt
Thank you very much for taking the time. At least, I now know that the third port in my case must be due to one of the other PJSIP modules which you didn’t load. Nevertheless, I’ll wait for your results before investigating further.
Unfortunately, the providers in Germany don’t have any clue what they are doing. They are not helpful when it comes to T.38; there is no chance to talk to somebody who knows about that matter. Even worse, some of them try to make you buy some hardware gateway which they claim to work flawlessly with their systems. I even suspect that they make their systems incompatible to standard T.38 by intention, hoping that they can force the customers to buy that crap that way.
So I don’t seem to have any chance to find out if the wrong owner actually is a problem.
I understand that the system call probably returns the respective NIC’s main address. But wouldn’t it be possible to use (one of) the configured address(es) from the transport(s) instead?
If I got you right, I can change the owner by configuring a media address. As soon as I have found out (still learning) how to do that, I’ll test and configure my public IP as media address. Then we’ll see if this has been the problem.
By the way, my IP address is pseudo-dynamic, meaning that it’s dynamic in principle, but the provider will change it very rarely (every 180 days or so), so it would be possible to update the configuration and restart Asterisk every time when this happens. I could imagine to write a script for that.
[SNIP]
Thanks to the hints you have given, if I find out how to configure the media address, I think I am able to change the owner line. Furthermore, I’ll try to let Asterisk bind to all IP addresses or to the main one; that way, the owner address would still be a local one, but the right of the local ones. I’ll report the results of these two tests.
Thank you very much,
Recursive
[SNIP]
[SNIP]
[SNIP]
In the meantime, I have tried to do some homework. I have made Asterisk bind to the main IP address of the box, and I have configured the local net and the external media address in the transport like that:
[tr_wZCMk5MvC2ATNzAr]
type = transport protocol = udp bind = 192.168.20.238
local_net = 192.168.20.0/24
local_net = 127.0.0.1/32
external_media_address = my.public.ip.address external_signaling_address = my.public.ip.address
Note that Asterisk now is bound to 192.168.20.238 (this is another IP address than in my last messages).
Interestingly, these changes had a subtle influence on when the communication goes wrong, compared to the situation I have described some days ago. Since the result is the same in the end (I still can’t send fax documents), I won’t go into the details here. At least, we can deduce that the wrong owner line is not the only problem (if it is a problem at all which I don’t believe any more).
For further analysis, I have let Wireshark create a call flow log which is here: http://www.omeganet.de/t38-call-flow-01.txt (sorry for the inconvenience, but the log is 41 kB, and the message size limit is 40 kB for this list).
I suspect that the problem is indicated by the log lines which show “T38:T30 ind:no signal”. I admit that I know nearly nothing about the details of fax protocols, so I hope somebody with appropriate knowledge is willing to take a look into the log and to tell me in simple words if these lines denote a normal situation or if they denote a problem.
Thank you very much,
Recursive