asterisk users - Dec 2014 - 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 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?

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.

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

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

>> 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.
> 
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.
> 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! :-)
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.
> 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
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?
> 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.
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]
> 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.
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

On 22.12.2014 14:58, Matthew Jordan wrote:
[SNIP]
> 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.
[SNIP] 
> 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:
[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