[Home]

Summary:ASTERISK-28993: res_pjsip: Wrong Via and Contact is chosen, despite explicit configured transport
Reporter:Marin Odrljin (modrljin)Labels:
Date Opened:2020-07-16 04:44:21Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents:Channels/chan_pjsip Resources/res_pjsip_sdp_rtp
Versions:16.11.0 Frequency of
Occurrence
Related
Issues:
Environment:Debian GNU/Linux 9Attachments:( 0) ari-app.log
( 1) full-log-filtered
( 2) http.conf
( 3) pjsip.conf
( 4) pjsip-new.conf
( 5) rtp.conf
Description:We are having multiple local IP addresses 10.5.20.42 ,.52, ,.62, ,.72 for multiple PJSIP trunks toward 2 different provider IP addresses. SIP INVITE sends SDP as following:
{code}
c=IN IP4 10.5.20.42
m=audio 12442 RTP/AVP 8 3 101
{code}
but UDP listening address is the last one .72:
{code}
ss -na
udp    UNCONN     0      0      10.5.20.72:12442                 *:*
{code}
So the result is no incoming RTP packets are comming into Asterisk - no IN audio.

Intersting thing is that in Asterisk 13 we have had the same configuration and it worked because Asterisk was listening on all IPs 0.0.0.0
Comments:By: Asterisk Team (asteriskteam) 2020-07-16 04:44:22.619-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
By: Marin Odrljin (modrljin) 2020-07-16 05:21:40.195-0500

asterisk config files
By: Joshua C. Colp (jcolp) 2020-07-16 05:26:43.922-0500

Does setting the "media_address" option and using "bind_rtp_to_media_address" resolve the problem?
By: Marin Odrljin (modrljin) 2020-07-16 07:11:37.475-0500

Yes, then it works. Thank you!
I've added to each endpoint the same IP address as it is defined in its transport (.42 - .72):
{code}
media_address=10.5.20.42
bind_rtp_to_media_address=yes
{code}

Asterisk listens on the same IP as stated in SDP and it does it correctly on each different IP as defined for each individual trunk.
So you think this is a quite common to define those parameters in such scenario when there are multiple local IP addresses? Transport binding is not enough?

However, I saw another interesting thing - SIP messages are always sent from the same IP 10.5.20.42 for all trunks binded to .42 - .72, at least that is written in Via header:
{code}
<--- History Entry 0 Sent to X.X.X.135:5060 at 1594897914 --->
OPTIONS sip:X.X.X.135 SIP/2.0
Via: SIP/2.0/UDP 10.5.20.42:5060;rport;branch=z9hG4bKPje47537b7-c33d-4ea7-ab3f-21b7efdb8b62
From: <sip:pjsip-swisscom-5@10.5.20.62>;tag=02ac0423-f5d0-4832-abcc-5421b07e8607
To: <sip:X.X.X.135>
Contact: <sip:pjsip-swisscom-5@10.5.20.42:5060>
Call-ID: d8f916a2-a6ce-460f-ad8d-57be052aecac
CSeq: 39466 OPTIONS
Max-Forwards: 70
User-Agent: Asterisk PBX 16.11.0
Content-Length:  0
{code}

You can see that in header From it is correct IP .62 while Via and Contact have .42. The same behaviour is with INVITE message. I have tried to add local_net into transport but it doesn't help.
By: Joshua C. Colp (jcolp) 2020-07-16 08:28:58.662-0500

People don't generally do what you're doing, or if they do they haven't had problems or filed them so I can't comment on what they do. It's not a common thing. The OPTIONS is sent differently, so the configured transport on the endpoint may not be getting applied.
By: Marin Odrljin (modrljin) 2020-07-16 09:44:33.703-0500

Ok, thank you for your answer. Here is the INVITE message which shows that the same behaviour is there:
{code}
INVITE sip:+41786144341@X.X.X.135 SIP/2.0
Via: SIP/2.0/UDP 10.5.20.42:5060;rport;branch=z9hG4bKPj199eb8e5-b0a8-4cda-b156-71f295492c45
From: <sip:+41413691000@10.5.20.72>;tag=8b2bd8e7-e2b1-4cd4-b265-4d971ba82290
To: <sip:+41786144341@X.X.X.135>
Contact: <sip:asterisk@10.5.20.42:5060>
Call-ID: f21caeaa-e059-4199-b4e2-d25053152f8e
CSeq: 6931 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 360
Max-Forwards: 70
User-Agent: Asterisk PBX 16.11.0
Content-Type: application/sdp
Content-Length:   256

v=0
o=- 1308455539 1308455539 IN IP4 10.5.20.72
s=Asterisk
c=IN IP4 10.5.20.72
t=0 0
m=audio 12442 RTP/AVP 8 3 101
...
{code}

This is a call that has transport and media address .72. In Via and Contact headers there is .42 while in From and SDP it is .72 (with media_address settings also now corrected in SDP). Luckily our ISP allows that because this is a kind of LAN traffic with them on all of those IPs. Different IPs are used for different trunks toward them for different clients. But I'm afraid that this is not completely correct - probably signalling should also go through the same corresponding transport IP.
By: Benjamin Keith Ford (bford) 2020-07-17 09:28:26.555-0500

Can you attach logs with SIP debugging[1] enabled so we can see the flow through Asterisk? The start of a call where things are being set up might show how the transport is being set. Bumping up debug and verbose levels would also help.

[1]: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
By: Marin Odrljin (modrljin) 2020-07-17 10:36:20.356-0500

Hi Benjamin, I will do that for sure, but unfortunatelly not in next 3 weeks, because I'm on the trip and while I'm gone this machine is reverted back to Asterisk 13 because it is a backup machine for production services and our client doesn't want to risk anything.
By: Benjamin Keith Ford (bford) 2020-07-17 11:03:30.071-0500

Sounds good. If this issue closes before you're able to post the results, just comment when you have the info and it will automatically reopen.
By: Asterisk Team (asteriskteam) 2020-07-31 12:00:00.932-0500

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines
By: Marin Odrljin (modrljin) 2020-08-20 05:39:42.381-0500

Attached new pjsip conf with endpoint options 'media_address' and 'bind_rtp_to_media_address'. Log file consists of incoming and outgoing pinging and one outbound call over PJSIP
By: Asterisk Team (asteriskteam) 2020-08-20 05:39:43.378-0500

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.
By: Marin Odrljin (modrljin) 2020-08-20 06:35:53.786-0500

I have attached my ARI app log file as well because I have found other strange issues related to PJSIP and reading out call data.

If you compare INVITE message SDP you'll see that local media address is set to 10.5.20.52:7366, but when app is reading 'CHANNEL(rtp,src,audio)' variable it gets back other value 10.5.20.42:7366 (ari-app.log line 24). Btw. 10.5.20.52 is correct one and audio works fine on that IP after setting 'media_address' into pjsip.conf, before that asterisk was using wrong IP.

A bit off topic, but our ARI app is trying to read some data on outbound PJSIP call via channel and pjsip functions, but unfortunatelly a lot of them doesn't work properly, e.g. reading CHANNEL(pjsip,remote_addr) or CHANNEL(pjsip,local_addr) returns 'Unable to read provided function'. Then PJSIP_HEADER(read,name) is available only on inbound channel. Is there any way to read out SIP headers such as From, To, Contact, Via etc. on outbound PJSIP call?
By: Joshua C. Colp (jcolp) 2020-08-20 06:54:16.402-0500

There is no ability that I'm aware of to read that kind of information. If it is present, it would be through the CHANNEL dialplan function like you've mentioned.
By: Marin Odrljin (modrljin) 2020-08-21 09:38:58.161-0500

I've just noticed one interesting thing in log. In the INVITE Via header is SIP/2.0/UDP 10.5.20.42:5060..., but in the response from ITSP asterisk gets back 'received' tag in Via header with correct IP 10.5.20.52. In the documentation it is written following: A received tag is added to a Via header field if a UA or proxy receives the request from a different address than that specified in the top Via header field. Does it means that asterisk sends INVITE over IP .52 but just sends wrong Via and Contact value?

{code}
[Aug 19 16:48:02] VERBOSE[2541] res_pjsip_logger.c: <--- Transmitting SIP request (921 bytes) to UDP:138.187.57.135:5060 --->
INVITE sip:+41786144341@138.187.57.135 SIP/2.0
Via: SIP/2.0/UDP 10.5.20.42:5060;rport;branch=z9hG4bKPj6516df3d-4f78-4fef-9ab9-9e89d94c2a67

[Aug 19 16:48:02] VERBOSE[2540] res_pjsip_logger.c: <--- Received SIP response (323 bytes) from UDP:138.187.57.135:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.5.20.42:5060;received=10.5.20.52;branch=z9hG4bKPj6516df3d-4f78-4fef-9ab9-9e89d94c2a67;rport=5060
{code}

It would be interesting in the future to add those information into logging such as:
res_pjsip_logger.c: <--- Transmitting SIP request (921 bytes) to UDP:138.187.57.135:5060 *from 10.5.20.52:5060* ---> and
res_pjsip_logger.c: <--- Received SIP response (323 bytes) from UDP:138.187.57.135:5060 *at 10.5.20.52:5060* --->
So we could immediately see from/to which local IP data were sent/received