[OpenSER-Devel] [ openser-Bugs-1983901 ] Retransmissions of 408 are not using received/rport from Via

[SourceForge.net]

Bugs item #1983901, was opened at 2008-06-03 16:52
Message generated for change (Comment added) made by apidruchny
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1983901&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: ver 1.3.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Anatoly Pidruchny (apidruchny)
Assigned to: Henning Westerholt (henningw)
Summary: Retransmissions of 408 are not using received/rport from Via

Initial Comment:
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 at hostA.com SIP/2.0
Via: SIP/2.0/UDP hostA.com:5060;branch=z9hG4bK0000167000167^M
From: 167 <sip:5105041000 at hostA.com>;tag=167^M
To: Receiver <sip:5105042000 at hostA.com>^M
Call-ID: 167 at 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 at hostA.com>;tag=167^M
To: Receiver <sip:5105042000 at hostA.com>;tag=2d7a0ab08b3494791197ebc7134d5742-0de7^M
Call-ID: 167 at 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 at hostA.com>;tag=167^M
To: Receiver <sip:5105042000 at hostA.com>;tag=2d7a0ab08b3494791197ebc7134d5742-4615^M
Call-ID: 167 at 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


----------------------------------------------------------------------

>Comment By: Anatoly Pidruchny (apidruchny)
Date: 2008-07-03 22:29

Message:
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.


----------------------------------------------------------------------

Comment By: Henning Westerholt (henningw)
Date: 2008-07-03 08:28

Message:
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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1983901&group_id=139143