Greetings fellow SIPers!
I've got a few questions regarding how I should interpret a few things
in
rfc3263, and related text in 3261.
===========
Question 1.
===========
3263 says:
If the URI specifies a transport protocol in the transport parameter,
that transport protocol SHOULD be used.
However, another transport, such as TCP,
MAY be used if the guidelines of SIP mandate it for this particular
request.
3261 says:
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP.
So if a client registers a Contact: with "IP:Port;transport=UDP",
does he also have to listen to TCP?
Since an incoming request just might be bigger than 1300 bytes...
...and vice versa...if he's registered ;transport=TCP, should/MUST he
listen to UDP, in case the incoming proxy is rfc2543 and doesnt support
TCP?
What you "should" do is one thing, what I am currently interessted in is
wether you risk violating any MUSTs with any special behavior.
===========
Question 2.
===========
Route preprocessing says, with regard to stripping the route header:
If the first value in the Route header field indicates this proxy,
the proxy MUST remove that value from the request.
All the other text in Ch. 16.4 regards the Request-URI and ;maddr
parameter,
so my question is.....Please Define: "indicates this proxy".
Do we have the same rules here as when matching the request-uri and
maddr?
In other words, if I receive a request with
Route: <sip:my-ipaddr:5063;transport=TCP>
but I receive it on UDP, should I strip it? What if the port is
different?
I want to do the same checks as for the request-uri, checking port,
transport,
etc, but the term "indicates this proxy", is a bit to vague for my
taste,
so I wouldnt mind hearing your views.
===========
Question 3.
===========
The annoying 503 Response and "Retry-After:".
I have actually read the archive and the fairly new RFC on
congestion-handling,
but neither seems to clarify, or even mention that the text in 3261,
(that is referred to in rfc5390) is completely self-contradicting,
to me at least!
3261:
If no Retry-After is given, the client MUST act as if it had
> received a 500 (Server Internal Error) response.
A client (proxy or UAC) receiving a 503 (Service Unavailable)
SHOULD attempt to forward the request to an alternate server.
It SHOULD NOT forward any other requests to that server for the
> duration specified in the Retry-After header field, if present.
To me, this says that any 503 response without R-A, is NOT a 503.
So how can the text in the next paragraph, say that if you receive
any kind of 503(even without Retry-After, since it says "if present")
you SHOULD retry somewhere else??
And then we have 3263, which generically says "if you receive a 503,
you should retry the next dns-rr". But since I always see 3261 as the
master-of-all-rules, I intepret this as you should ONLY perform this
retry, IF the 503 you just got, HAD a Retry-After.
Since we've already defined that a 503 w/o R-A, is not, in fact, a 503
but a 500.....or have we? :-@
So. If my proxy receives a 503 without R-A, should I, according to
3261/3
fetch the next RR and retry?
===========
Question 4.
===========
This is quite related to the retrying mechanism above, from 3263.
It concerns the text about retrying after fatal transport errors, using
a "completely" new transaction:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RFC 3263
4.3 Details of RFC 2782 Process
...Failure also occurs if the transaction layer times out without
ever
having received any response, provisional or final
....
If a failure occurs, the client
SHOULD create a new request, which is identical to the previous, but
has a different value of the Via branch ID than the previous (and
therefore constitutes a new SIP transaction).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The text says the "this constitutes a new transaction", but nothing
more, and I find that it leaves the question of restarting Timer C
and Timer F/B up to interpretation.
Should I restart Timer C and/or Timer B/F when I create this new txn?
My first assumption would be not to, but the text says quite clearly
that it "constitutes a new transaction", and a new txn has a new
Timer F, as well as
- - - - -
RFC3261, Chapter 16.6 Request Forwarding, (bullet 11)
Timer C MUST be set for each client transaction when an INVITE request
is proxied.
- - - - -
..which could imply that even Timer C should be restarted why you retry
on the next available SRV-record after failure.
But doing this naturally means that a non-INVITE that fails towards
a destination with 3 usable SRV records, will take 3*64T1 to complete,
whereas the previous hop times out after Timer F as always.
So, when reading rfc4320/21 where they clearly *imply* that you should
NOT
restart these Timers, I just though I would see if I could get some
confirmation on this interpretation.
I'd be very interessted, and thankful for whatever feedback you folks
can provide.
Thanks in advanced
Regards
Taisto Qvist
IP-Solutions AB
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
