[asterisk-users] PJSIP ports, multiple IP addresses and wrong owner
Matthew Jordan
mjordan at digium.com
Mon Dec 22 07:58:07 CST 2014
On Sun, Dec 21, 2014 at 4:54 AM, Recursive <lists at binarus.de> wrote:
> 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 at 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?
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.
> 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 at 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 at itsp.de SIP/2.0
> Method: INVITE
> Request-URI: sip:00498234xxxxxxx at 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:77748zb1ye at fpbx.de>;tag=4e855dd1-4a8c-41a9-9524-038d32c08ce3
> SIP from address: sip:username at 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:004982349663847 at fpbx.de>
> SIP to address: sip:00498234xxxxxxx at itsp.de
> SIP to address User Part: 00498234xxxxxxx
> SIP to address Host Part: itsp.de
> Contact: <sip:username at yy.yyy.yy.yyy>
> Contact URI: sip:username at 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.
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
username and IP address of the session originator. If this is a
concern, an arbitrary <username> and private <unicast-address> MAY be
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}
> 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?
>
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
--
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
More information about the asterisk-users
mailing list