Force SIP response to TCP 5060

When I changed the channel drive to chan_sip to chan_pjsip, the SIP response to OPTIONS request was changed, it was used to response to TCP port 5060 in chan_sip, but in chan_pjsip it is responding to original port of the request, is there any way I can force it to respond to TCP port 5060?

Debug log for reference:

CHAN_SIP:

<— SIP read from TCP:x.x.31.40:29778 —>
OPTIONS sip:asterisk SIP/2.0
From: < sip:x.x.31.40 >;tag=809ea16429d9e8179a05bd6969100
To: < sip:asterisk >
Call-ID: 809ea16429d9e8179a05bd6969100
CSeq: 21003 OPTIONS
Max-Forwards: 70
Via: SIP/2.0/TCP x.x.31.40;branch=z9hG4bK809ea16429d9e817aa05bd6969100
User-Agent: Avaya CM/R016x.03.0.124.0
Contact: < sip:invalid x.x.31.40;transport=tcp >
Route: < sip:x.x.34.155;transport=tcp;lr >
Expires: 0
Content-Length: 0

<— Transmitting (no NAT) to x.x.31.40:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/TCP x.x.31.40;branch=z9hG4bK809ea16429d9e817aa05bd6969100;received=x.x.31.40
From: < sip:x.x.31.40 >;tag=809ea16429d9e8179a05bd6969100
To: < sip:asterisk >;tag=as689d17f2
Call-ID: 809ea16429d9e8179a05bd6969100
CSeq: 21003 OPTIONS
Server: Asterisk PBX 16.0.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: < sip:x.x.34.155:5060;transport=tcp >
Accept: application/sdp
Content-Length: 0

CHAN_PJSIP:

<— Received SIP request (439 bytes) from TCP:x.x.31.40:26243 —>
OPTIONS sip:asterisk SIP/2.0
From: < sip:x.x.31.40 >;tag=0fed5a02bd9e8158a65bd6969100
To: < sip:asterisk >
Call-ID: 0fed5a02bd9e8158a65bd6969100
CSeq: 27168 OPTIONS
Max-Forwards: 70
Via: SIP/2.0/TCP x.x.31.40;branch=z9hG4bK0fed5a02bd9e8159a65bd6969100
User-Agent: Avaya CM/R016x.03.0.124.0
Contact: < sip:invalid x.x.31.40;transport=tcp >
Route: < sip:x.x.34.155;transport=tcp;lr >
Expires: 0
Content-Length: 0

<— Transmitting SIP response (522 bytes) to TCP:x.x.31.40:26243 —>
SIP/2.0 200 OK
Via: SIP/2.0/TCP x.x.31.40;received=x.x.31.40;branch=z9hG4bK0fed5a02bd9e8159a65bd6969100
Call-ID: 0fed5a02bd9e8158a65bd6969100
From: < sip:x.x.31.40 >;tag=0fed5a02bd9e8158a65bd6969100
To: < sip:asterisk >;tag=z9hG4bK0fed5a02bd9e8159a65bd6969100
CSeq: 27168 OPTIONS
Accept: application/sdp
Allow: OPTIONS, REGISTER, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE
Supported: 100rel, timer
Accept-Encoding: text/plain
Accept-Language: en
Server: Asterisk PBX 16.0.0
Content-Length: 0

That sounds like a bug in chan_sip!!

The correct way of operating is to complete transactions on the same TCP connection.

If chan_sip is also doing this for INVITE transactions, it will compromising the ability not to send ACK on TCP sessions.

But the other end (i.e. Avaya in our case) is expecting the response sent to port 5060 (the configured listen port). This is working fine for us while we use chan_sip.

It’s broken. If it really wants that behaviour, it should close the TCP session on the last packet of the OPTIONs request. Even then, TCP has half closes, to it would be legitimate, from a TCP point of view, to respond on the same connection.

Avaya are requiring you to break a mandatory (MUST) requirement of RFC 3261 (see first bullet point in 10.2.2).

You can try ensuring “rewrite_contact” is set to “no” and “force_rport” is set to “no”.