VoIP Mailing List Archives :: View topic - [asterisk-users] PJSIP ports, multiple IP addresses and wrong owner

Sponsor: VoiceMeUp - Corporate & Wholesale VoIP Services

VoIP Mailing List Archives
Mailing list archives for the VoIP community

[asterisk-users] PJSIP ports, multiple IP addresses and wrong owner

VoIP Mailing List Archives Forum Index -> Asterisk Users

View previous topic :: View next topic

Author

Message

lists at binarus.de
Guest

Posted: Sun Dec 21, 2014 5:54 am Post subject: [asterisk-users] PJSIP ports, multiple IP addresses and wron

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:1 Internet Protocol Version 4, Src: 192.168.20.48 (192.168.20.4, 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:77748zb1ye@fpbx.de>;tag=4e855dd1-4a8c-41a9-9524-038d32c08ce3 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:004982349663847@fpbx.de> SIP to address: sip:00498234xxxxxxx@itsp.de SIP to address User Part: 00498234xxxxxxx SIP to address Host Part: itsp.de Contact: <sip:username@yy.yyy.yy.yyy> 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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users

mjordan at digium.com
Guest

Posted: Mon Dec 22, 2014 8:58 am Post subject: [asterisk-users] PJSIP ports, multiple IP addresses and wron

On Sun, Dec 21, 2014 at 4:54 AM, Recursive <lists@binarus.de> wrote:

Quote:

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?

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.

Quote:

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:1 Cool

Internet Protocol Version 4, Src: 192.168.20.48 (192.168.20.4 Cool

, 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:77748zb1ye@fpbx.de>;tag=4e855dd1-4a8c-41a9-9524-038d32c08ce3
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:004982349663847@fpbx.de>
SIP to address: sip:00498234xxxxxxx@itsp.de
SIP to address User Part: 00498234xxxxxxx
SIP to address Host Part: itsp.de
Contact: <sip:username@yy.yyy.yy.yyy>
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.

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! Smile

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}

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

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

lists at binarus.de
Guest

Posted: Fri Dec 26, 2014 4:06 am Post subject: [asterisk-users] PJSIP ports, multiple IP addresses and wron

Quote:

So what is the meaning of the additional ports PJSIP is opening, and why does it open these on all IP addresses?

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.

Quote:

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! Smile

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.

Quote:

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?

Quote:

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]

Quote:

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

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

lists at binarus.de
Guest

Posted: Sun Dec 28, 2014 11:56 am Post subject: [asterisk-users] PJSIP ports, multiple IP addresses and wron

On 22.12.2014 14:58, Matthew Jordan wrote:
[SNIP]

Quote:

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]

Quote:

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

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

Display posts from previous:

	VoIP Mailing List Archives Forum Index -> Asterisk Users	All times are GMT - 5 Hours
Page 1 of 1

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum