#467 Retransmissions of 408 are not using received/rport from Via

[Anatoly Pidruchny]

When fr_timer/fr_inv_timer expires for an INVITE transaction, OpenSER generates 408 Request Timeout reply. The first time the 408 reply is sent to the host/port that was saved in the received/rport parameters in Via header. But if the UAC does not send ACK and OpenSER starts retransmissions of the 408 reply, it is sent to the host/port in the Via header value, received/rport are not used any more.

I will try to provide the SIP message flow. Let's say OpenSER received and later relayed the following message:

INVITE sip:5105042000@hostA.com SIP/2.0
Via: SIP/2.0/UDP hostA.com:5060;branch=z9hG4bK0000167000167^M
From: 167 <sip:5105041000@hostA.com>;tag=167^M
To: Receiver <sip:5105042000@hostA.com>^M
Call-ID: 167@hostA.com^M
CSeq: 1 INVITE^M
Content-Length: 0^M
^M

Yes, UAC put the domain name of the OpenSER machine into the Via header. This is part of some SIP security test suite and so it was done on purpose. OpenSER added received/rport parameters into the Via header:

Via: SIP/2.0/UDP hostA.com:5060;branch=z9hG4bK0000167000167;rport=5060;received=10.104.49.186^M

When fr_timer or fr_inv_timer expires for this message, OpenSER sends the following reply to the UAC on host 10.104.49.186, port 5060:

SIP/2.0 408 Request Timeout^M
Via: SIP/2.0/UDP hostA.com:5060;branch=z9hG4bK0000167000167;rport=5060;received=10.104.49.186^M
From: 167 <sip:5105041000@hostA.com>;tag=167^M
To: Receiver <sip:5105042000@hostA.com>;tag=2d7a0ab08b3494791197ebc7134d5742-0de7^M
Call-ID: 167@hostA.com^M
CSeq: 1 INVITE^M
Content-Length: 0^M
^M

But UAC did not answer with ACK, so then OpenSER started retransmitting the 408 reply. But the retransmissions did not go to host 10.104.49.186, port 5060. They were sent back to OpenSER's machine hostA.com that was in the value of the Via header. The first retransmission looked like this:

SIP/2.0 408 Request Timeout^M
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx;branch=z9hG4bKe568.6c360a02.0^M
Via: SIP/2.0/UDP hostA.com:5060;rport=5060;received=10.104.49.186;branch=z9hG4bK0000167000167^M
From: 167 <sip:5105041000@hostA.com>;tag=167^M
To: Receiver <sip:5105042000@hostA.com>;tag=2d7a0ab08b3494791197ebc7134d5742-4615^M
Call-ID: 167@hostA.com^M
CSeq: 1 INVITE^M
Content-Length: 0^M
^M

Subsequent retransmissions kept adding the Via header:
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx;branch=z9hG4bKe568.xxxxxxxx.0^M

[Henning Westerholt]

Logged In: YES
user_id=337916
Originator: NO

Hi Anatoly

this UAC behaviour is not valid according to the RFC:

8.1.1.7 Via
The Via header field indicates the transport used for the transaction
and identifies the location where the response is to be sent.

I've tried to reproduce this anyway, and my openser loops subsequent messages (1XX, 408) as expected. Can you give more details why do you think this is a bug?

Henning

[Anatoly Pidruchny]

Logged In: YES
user_id=1759384
Originator: YES

Hi, Henning,

sure, the UAC put wrong value into the Via, because it is not a "real" UAC, it is just some kind of a test engine. Still, what OpenSER did in that case was not right.

Why did you mention 1xx reply in your comment? No offense, may be my explanations is not clear enough, but I suspect that you did not really understand what is this bug report is about. When OpenSER generated the 408 reply, it sent it correctly to the host/port that was stored in the received/rport parameters of the Via header. Later, when OpenSER started to re-transmit this same 408 reply (not some other subsequent messages, as you mentioned in your comment), it ignored the receied/rport parameters in the Via header and sent them to whatever host/port was in the Via header value itself and ignored received/rport parameters. And this is, obviously, not correct.

Thanks,

Anatoly.

[Henning Westerholt]

Logged In: YES
user_id=337916
Originator: NO

Hi Anatoly,

i've tried to reproduce this with some sipp scenario, as i don't have access to your test engine. That was the reason i talked about 1XX replies.

Henning