[Sip-implementors] 416 Unsupported Uri Scheme

[isshed]

Hi All,

Below is the scenario.

UAC-------------------------------------------------UAS

1) ==========INVITE(tel req uri)============>
2) <==========100 trying ==============
3) <==========416 Unsupported URI=======
4) ========Re-Invite==================>

I have a doubt on this 4th message which UAC is sending. As per RFC 3261.

"If a 416 (Unsupported URI Scheme) response is received (Section 21.4.14),
the Request-URI used a URI scheme not supported by the server. The
client SHOULD
retry the request, this time, using a SIP URI.
.
.
.
.
In all of the above cases, the request is retried by creating a new request
with the appropriate modifications. This new request constitutes a new
transaction
and SHOULD have the same value of the Call-ID, To, and From of the previous
request, but the CSeq should contain a new sequence number that is one
higher than the previous.
"

If suppose first INVITE message and To header are of tel URI type. And the
server responds with 416. Should we not be changing the To header from tel
URI to SIP URI in this case? Is it enough to change only Req Uri from tel
to sip? And if we change the To header then we would be voilating the RFC
3261.

Please help me understand this scenario.
Is there any other specs/rfc for translating tel URI to sip sip URI other
than RFC 3261/3966?


Thanks,
Isshed.

[Paul Kyzivat]

Post by isshed
Hi All,
Below is the scenario.
UAC-------------------------------------------------UAS
1) ==========INVITE(tel req uri)============>
2) <==========100 trying ==============
3) <==========416 Unsupported URI=======
4) ========Re-Invite==================>
I have a doubt on this 4th message which UAC is sending. As per RFC 3261.
"If a 416 (Unsupported URI Scheme) response is received (Section 21.4.14),
the Request-URI used a URI scheme not supported by the server. The
client SHOULD
retry the request, this time, using a SIP URI.
.
.
.
.
In all of the above cases, the request is retried by creating a new request
with the appropriate modifications. This new request constitutes a new
transaction
and SHOULD have the same value of the Call-ID, To, and From of the previous
request, but the CSeq should contain a new sequence number that is one
higher than the previous.
"
If suppose first INVITE message and To header are of tel URI type. And the
server responds with 416. Should we not be changing the To header from tel
URI to SIP URI in this case? Is it enough to change only Req Uri from tel
to sip? And if we change the To header then we would be voilating the RFC
3261.
Please help me understand this scenario.
Is there any other specs/rfc for translating tel URI to sip sip URI other
than RFC 3261/3966?

I'm not aware of anything else that discusses this.

IMO the answer to your question depends upon how the UAC chooses the
replacement URI.

If this is an algorithmic replacement then the UA is essentially acting
as a proxy would - "routing" the request to an intermediate destination
than can help get it where it is going. In this case it should leave the
To-uri unchanged, as a proxy would.

OTOH, if the UAC goes back to its address book and looks for a different
URI that identifies the intended recipient, then it should also replace
the To-uri.

Good Luck,
Paul

[Brett Tate]

Post by isshed
If suppose first INVITE message and To header are of
tel URI type. And the server responds with 416. Should
we not be changing the To header from tel URI to
SIP URI in this case?

According to RFC 3261, the request-URI was the issue. As section 8.1.3.5 indicates, the To SHOULD be the same. However if you want to change the To URI (and/or From URI), I recommend changing the Call-ID since you are effectively acting more like a 3xx processing option (section 8.1.3.4) which indicates that the Call-ID MAY change.

RFC 3261 is underspecified concerning the topic since the UAC and proxies theoretically have no idea which request-URI caused the issue. For instance, "tel" might be supported; however the proxy forwarded the call to another server using a "foo" request-URI scheme.

[isshed]

Thank you Brett!!

Post by Brett Tate

Post by isshed
If suppose first INVITE message and To header are of
tel URI type. And the server responds with 416. Should
we not be changing the To header from tel URI to
SIP URI in this case?

According to RFC 3261, the request-URI was the issue. As section 8.1.3.5
indicates, the To SHOULD be the same. However if you want to change the To
URI (and/or From URI), I recommend changing the Call-ID since you are
effectively acting more like a 3xx processing option (section 8.1.3.4)
which indicates that the Call-ID MAY change.
RFC 3261 is underspecified concerning the topic since the UAC and proxies
theoretically have no idea which request-URI caused the issue. For
instance, "tel" might be supported; however the proxy forwarded the call to
another server using a "foo" request-URI scheme.