Subject: Re: [sipcore] [Technical Errata Reported] RFC7118 (5937)

From: Roman Shpount <[email-masked]>
Date: Sat, 14 Dec 2019 15:42:33 -0500

It looks like RFC 5630 allows this and there is a description of such flow
in  https://tools.ietf.org/html/rfc5630#section-6.4.

Please disregard this errata.
_____________
Roman Shpount

On Sat, Dec 14, 2019 at 3:18 PM Roman Shpount <[email-masked]> wrote:

> If you look at this message:
>
> INVITE sip:[email-masked] SIP/2.0
> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
> From: sip:[email-masked];tag=asdyka899
> To: sip:[email-masked]
> Call-ID: asidkj3ss
> CSeq: 1 INVITE
> Max-Forwards: 70
> Supported: path, outbound, gruu
> Route: <sip:proxy.example.com:443;transport=ws;lr>
> Contact: <sip:[email-masked];gr=urn:uuid:f81-7dec-14a06cf1;ob>
> Content-Type: application/sdp
>
> Then WS, not WSS should be used to send it. In order for WSS to be used,
> Route header should be "Route: <sip*s*:proxy.example.com:443;tra
> nsport=ws;lr>" .
>
> There is currently no standard compliant way to send a SIP message over
> WSS (or any other secure protocol) and then have it forwarded over an
> insecure protocol (UDP). Current example implies this is possible.
> _____________
> Roman Shpount
>
>
> On Sat, Dec 14, 2019 at 3:08 PM Iñaki Baz Castillo <[email-masked]> wrote:
>
>> As replied in JsSIP mailing list, this is not a bug in 7118 but a general
>> design issue in RFC 3261.
>>
>> El sáb., 14 dic. 2019 21:06, RFC Errata System <[email-masked]>
>> escribió:
>>
>>> The following errata report has been submitted for RFC7118,
>>> "The WebSocket Protocol as a Transport for the Session Initiation
>>> Protocol (SIP)".
>>>
>>> --------------------------------------
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid5937
>>>
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Roman Shpount <[email-masked]>
>>>
>>> Section: 8.2
>>>
>>> Original Text
>>> -------------
>>> INVITE sip:[email-masked] SIP/2.0
>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
>>> From: sip:[email-masked];tag=asdyka899
>>> To: sip:[email-masked]
>>> Call-ID: asidkj3ss
>>> CSeq: 1 INVITE
>>> Max-Forwards: 70
>>> Supported: path, outbound, gruu
>>> Route: <sip:proxy.example.com:443;transport=ws;lr>
>>> Contact: <sip:[email-masked];gr=urn:uuid:f81-7dec-14a06cf1;ob>
>>> Content-Type: application/sdp
>>>
>>>
>>> F2 100 Trying  proxy.example.com -> Alice (transport WSS)
>>>
>>> SIP/2.0 100 Trying
>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
>>> From: sip:[email-masked];tag=asdyka899
>>> To: sip:[email-masked]
>>> Call-ID: asidkj3ss
>>> CSeq: 1 INVITE
>>>
>>>
>>> F3 INVITE  proxy.example.com -> Bob (transport UDP)
>>>
>>> INVITE sip:[email-masked]:5060 SIP/2.0
>>> Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c
>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
>>> Record-Route: <sip:proxy.example.com;transport=udp;lr>,
>>>  <sip:[email-masked]:443;transport=wss;lr>
>>> From: sip:[email-masked];tag=asdyka899
>>> To: sip:[email-masked]
>>> Call-ID: asidkj3ss
>>> CSeq: 1 INVITE
>>> Max-Forwards: 69
>>> Supported: path, outbound, gruu
>>> Contact: <sip:[email-masked];gr=urn:uuid:f81-7dec-14a06cf1;ob>
>>> Content-Type: application/sdp
>>>
>>> F4 200 OK  Bob -> proxy.example.com (transport UDP)
>>>
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c
>>>  ;received=192.0.2.10
>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
>>> Record-Route: <sip:proxy.example.com;transport=udp;lr>,
>>>  <sip:[email-masked]:443;transport=ws;lr>
>>> From: sip:[email-masked];tag=asdyka899
>>> To: sip:[email-masked];tag=bmqkjhsd
>>> Call-ID: asidkj3ss
>>> CSeq: 1 INVITE
>>> Contact: <sip:[email-masked]:5060;transport=udp>
>>> Content-Type: application/sdp
>>>
>>>
>>> F5 200 OK  proxy.example.com -> Alice (transport WSS)
>>>
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
>>> Record-Route: <sip:proxy.example.com;transport=udp;lr>,
>>>  <sip:[email-masked]:443;transport=ws;lr>
>>> From: sip:[email-masked];tag=asdyka899
>>> To: sip:[email-masked];tag=bmqkjhsd
>>> Call-ID: asidkj3ss
>>> CSeq: 1 INVITE
>>> Contact: <sip:[email-masked]:5060;transport=udp>
>>> Content-Type: application/sdp
>>>
>>>
>>> F6 ACK  Alice -> proxy.example.com (transport WSS)
>>>
>>> ACK sip:[email-masked]:5060;transport=udp SIP/2.0
>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090
>>> Route: <sip:[email-masked]:443;transport=ws;lr>,
>>>  <sip:proxy.example.com;transport=udp;lr>,
>>> From: sip:[email-masked];tag=asdyka899
>>> To: sip:[email-masked];tag=bmqkjhsd
>>> Call-ID: asidkj3ss
>>> CSeq: 1 ACK
>>> Max-Forwards: 70
>>>
>>> F7 ACK  proxy.example.com -> Bob (transport UDP)
>>>
>>> ACK sip:[email-masked]:5060;transport=udp SIP/2.0
>>> Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhwpoc80zzx
>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090
>>> From: sip:[email-masked];tag=asdyka899
>>> To: sip:[email-masked];tag=bmqkjhsd
>>> Call-ID: asidkj3ss
>>> CSeq: 1 ACK
>>> Max-Forwards: 69
>>>
>>>
>>> F8 BYE  Bob -> proxy.example.com (transport UDP)
>>>
>>> BYE sip:[email-masked];gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0
>>> Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
>>> Route: <sip:proxy.example.com;transport=udp;lr>,
>>>  <sip:[email-masked]:443;transport=ws;lr>
>>> From: sip:[email-masked];tag=bmqkjhsd
>>> To: sip:[email-masked];tag=asdyka899
>>> Call-ID: asidkj3ss
>>> CSeq: 1201 BYE
>>> Max-Forwards: 70
>>>
>>>
>>> F9 BYE  proxy.example.com -> Alice (transport WSS)
>>>
>>> BYE sip:[email-masked];gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0
>>> Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5
>>> Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
>>> From: sip:[email-masked];tag=bmqkjhsd
>>> To: sip:[email-masked];tag=asdyka899
>>> Call-ID: asidkj3ss
>>> CSeq: 1201 BYE
>>> Max-Forwards: 69
>>>
>>>
>>> F10 200 OK  Alice -> proxy.example.com (transport WSS)
>>>
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5
>>> Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
>>> From: sip:[email-masked];tag=bmqkjhsd
>>> To: sip:[email-masked];tag=asdyka899
>>> Call-ID: asidkj3ss
>>> CSeq: 1201 BYE
>>>
>>>
>>> F11 200 OK  proxy.example.com -> Bob (transport UDP)
>>>
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
>>> From: sip:[email-masked];tag=bmqkjhsd
>>> To: sip:[email-masked];tag=asdyka899
>>> Call-ID: asidkj3ss
>>> CSeq: 1201 BYE
>>>
>>> Corrected Text
>>> --------------
>>> F1 INVITE  Alice -> proxy.example.com (transport WSS)
>>>
>>> INVITE sips:[email-masked] SIP/2.0
>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
>>> From: sips:[email-masked];tag=asdyka899
>>> To: sips:[email-masked]
>>> Call-ID: asidkj3ss
>>> CSeq: 1 INVITE
>>> Max-Forwards: 70
>>> Supported: path, outbound, gruu
>>> Route: <sips:proxy.example.com:443;transport=wss;lr>
>>> Contact: <sips:[email-masked];gr=urn:uuid:f81-7dec-14a06cf1;ob>
>>> Content-Type: application/sdp
>>>
>>>
>>> F2 100 Trying  proxy.example.com -> Alice (transport WSS)
>>>
>>> SIP/2.0 100 Trying
>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
>>> From: sips:[email-masked];tag=asdyka899
>>> To: sips:[email-masked]
>>> Call-ID: asidkj3ss
>>> CSeq: 1 INVITE
>>>
>>>
>>> F3 INVITE  proxy.example.com -> Bob (transport TLS)
>>>
>>> INVITE sips:[email-masked] SIP/2.0
>>> Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bKhjhjqw32c
>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
>>> Record-Route: <sips:proxy.example.com;lr>,
>>>  <sips:[email-masked]:443;transport=ws;lr>
>>> From: sip:[email-masked];tag=asdyka899
>>> To: sips:[email-masked]
>>> Call-ID: asidkj3ss
>>> CSeq: 1 INVITE
>>> Max-Forwards: 69
>>> Supported: path, outbound, gruu
>>> Contact: <sips:[email-masked]
>>>  ;gr=urn:uuid:f81-7dec-14a06cf1;ob>
>>> Content-Type: application/sdp
>>>
>>> F4 200 OK  Bob -> proxy.example.com (transport TLS)
>>>
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bKhjhjqw32c
>>>  ;received=192.0.2.10
>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
>>> Record-Route: <sips:proxy.example.com;lr>,
>>>  <sips:[email-masked]:443;transport=ws;lr>
>>> From: sips:[email-masked];tag=asdyka899
>>> To: sips:[email-masked];tag=bmqkjhsd
>>> Call-ID: asidkj3ss
>>> CSeq: 1 INVITE
>>> Contact: <sips:[email-masked]>
>>> Content-Type: application/sdp
>>>
>>>
>>> F5 200 OK  proxy.example.com -> Alice (transport WSS)
>>>
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
>>> Record-Route: <sips:proxy.example.com;lr>,
>>>  <sips:[email-masked]:443;transport=ws;lr>
>>> From: sips:[email-masked];tag=asdyka899
>>> To: sips:[email-masked];tag=bmqkjhsd
>>> Call-ID: asidkj3ss
>>> CSeq: 1 INVITE
>>> Contact: <sips:[email-masked]>
>>> Content-Type: application/sdp
>>>
>>>
>>> F6 ACK  Alice -> proxy.example.com (transport WSS)
>>>
>>> ACK sips:[email-masked] SIP/2.0
>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090
>>> Route: <sips:[email-masked]:443;transport=ws;lr>,
>>>  <sips:proxy.example.com;lr>,
>>> From: sips:[email-masked];tag=asdyka899
>>> To: sips:[email-masked];tag=bmqkjhsd
>>> Call-ID: asidkj3ss
>>> CSeq: 1 ACK
>>> Max-Forwards: 70
>>>
>>> F7 ACK  proxy.example.com -> Bob (transport TLS)
>>>
>>> ACK sips:[email-masked] SIP/2.0
>>> Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bKhwpoc80zzx
>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090
>>> From: sips:[email-masked];tag=asdyka899
>>> To: sips:[email-masked];tag=bmqkjhsd
>>> Call-ID: asidkj3ss
>>> CSeq: 1 ACK
>>> Max-Forwards: 69
>>>
>>>
>>> F8 BYE  Bob -> proxy.example.com (transport TLS)
>>>
>>> BYE sips:[email-masked];gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0
>>> Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001
>>> Route: <sips:proxy.example.com;lr>,
>>>  <sips:[email-masked]:443;transport=ws;lr>
>>> From: sips:[email-masked];tag=bmqkjhsd
>>> To: sips:[email-masked];tag=asdyka899
>>> Call-ID: asidkj3ss
>>> CSeq: 1201 BYE
>>> Max-Forwards: 70
>>>
>>>
>>> F9 BYE  proxy.example.com -> Alice (transport WSS)
>>>
>>> BYE sips:[email-masked];gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0
>>> Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5
>>> Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001
>>> From: sips:[email-masked];tag=bmqkjhsd
>>> To: sips:[email-masked];tag=asdyka899
>>> Call-ID: asidkj3ss
>>> CSeq: 1201 BYE
>>> Max-Forwards: 69
>>>
>>>
>>> F10 200 OK  Alice -> proxy.example.com (transport WSS)
>>>
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5
>>> Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001
>>> From: sips:[email-masked];tag=bmqkjhsd
>>> To: sips:[email-masked];tag=asdyka899
>>> Call-ID: asidkj3ss
>>> CSeq: 1201 BYE
>>>
>>>
>>> F11 200 OK  proxy.example.com -> Bob (transport TLS)
>>>
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001
>>> From: sips:[email-masked];tag=bmqkjhsd
>>> To: sips:[email-masked];tag=asdyka899
>>> Call-ID: asidkj3ss
>>> CSeq: 1201 BYE
>>>
>>> Notes
>>> -----
>>> This example states that WSS protocol is used, but Route header
>>> specifies SIP URI with transport=ws. which would mean WS (insecure Web
>>> Socket). Furthermore, if SIPS URI is used in Route header, then all other
>>> URI must be SIPS as well and message cannot be forwarded over UDP, SIPS
>>> over TLS must be used instead. I have modified the entire example to use
>>> SIPS and TLS, instead of SIP and UDP.
>>>
>>> Instructions:
>>> -------------
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party
>>> can log in to change the status and edit the report, if necessary.
>>>
>>> --------------------------------------
>>> RFC7118 (draft-ietf-sipcore-sip-websocket-10)
>>> --------------------------------------
>>> Title               : The WebSocket Protocol as a Transport for the
>>> Session Initiation Protocol (SIP)
>>> Publication Date    : January 2014
>>> Author(s)           : I. Baz Castillo, J. Millan Villegas, V. Pascual
>>> Category            : PROPOSED STANDARD
>>> Source              : Session Initiation Protocol Core RAI
>>> Area                : Real-time Applications and Infrastructure
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>>
>>

---

From: RFC Errata System <[email-masked]>
Date: Sat, 14 Dec 2019 12:06:23 -0800 (PST)

The following errata report has been submitted for RFC7118,
"The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)".

Section: 8.2

Original Text
-------------

SIP/2.0 100 Trying

SIP/2.0 200 OK

SIP/2.0 200 OK

SIP/2.0 200 OK

SIP/2.0 200 OK

Corrected Text
--------------

SIP/2.0 100 Trying

SIP/2.0 200 OK

SIP/2.0 200 OK

SIP/2.0 200 OK

SIP/2.0 200 OK

Notes
-----
This example states that WSS protocol is used, but Route header specifies SIP URI with transport=ws. which would mean WS (insecure Web Socket). Furthermore, if SIPS URI is used in Route header, then all other URI must be SIPS as well and message cannot be forwarded over UDP, SIPS over TLS must be used instead. I have modified the entire example to use SIPS and TLS, instead of SIP and UDP.

Instructions:
-------------

Title               : The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 14 Dec 2019 21:07:52 +0100

El sáb., 14 dic. 2019 21:06, RFC Errata System <[email-masked]>
escribió:

> This example states that WSS protocol is used, but Route header specifies
> SIP URI with transport=ws. which would mean WS (insecure Web Socket).
> Furthermore, if SIPS URI is used in Route header, then all other URI must
> be SIPS as well and message cannot be forwarded over UDP, SIPS over TLS
> must be used instead. I have modified the entire example to use SIPS and
> TLS, instead of SIP and UDP.
>
> Instructions:
> -------------

---

From: Roman Shpount <[email-masked]>
Date: Sat, 14 Dec 2019 15:18:31 -0500

There is currently no standard compliant way to send a SIP message over WSS
(or any other secure protocol) and then have it forwarded over an insecure
protocol (UDP). Current example implies this is possible.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 15 Dec 2019 23:54:39 +0100

Yeah, that's exactly the section I meant :)

On Sat, 14 Dec 2019 at 21:42, Roman Shpount <[email-masked]> wrote:
>
> It looks like RFC 5630 allows this and there is a description of such flow in  https://tools.ietf.org/html/rfc5630#section-6.4.
>
>> Then WS, not WSS should be used to send it. In order for WSS to be used, Route header should be "Route: <sips:proxy.example.com:443;transport=ws;lr>" .
>>
>> There is currently no standard compliant way to send a SIP message over WSS (or any other secure protocol) and then have it forwarded over an insecure protocol (UDP). Current example implies this is possible.
>> _____________
>> Roman Shpount
>>
>>
>>> As replied in JsSIP mailing list, this is not a bug in 7118 but a general design issue in RFC 3261.
>>>
>>> El sáb., 14 dic. 2019 21:06, RFC Errata System <[email-masked]> escribió:
>>>>

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 19 Dec 2019 10:06:15 -0500

On Sun, Dec 15, 2019 at 5:54 PM Iñaki Baz Castillo <[email-masked]> wrote:

> > It looks like RFC 5630 allows this and there is a description of such
> flow in  https://tools.ietf.org/html/rfc5630#section-6.4.
>
>
One small nit that in the RFC7118 example, according to
https://tools.ietf.org/html/rfc5630#section-6.4, there should not be
"transport=ws" or any other transport in the URI in the Route header. Since
this Route URI is simply there for the proxy to identify that the message
was correctly routed and remove, this is just a nit.

Best Regards,
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 19 Dec 2019 17:26:07 +0100

On Thu, 19 Dec 2019 at 16:06, Roman Shpount <[email-masked]> wrote:
> One small nit that in the RFC7118 example, according to https://tools.ietf.org/html/rfc5630#section-6.4, there should not be "transport=ws" or any other transport in the URI in the Route header. Since this Route URI is simply there for the proxy to identify that the message was correctly routed and remove, this is just a nit.

I don't think there is a MUST NOT for that, nor that such a
transport=ws is really invalid, is it?

---

From: Roman Shpount <[email-masked]>
Date: Thu, 19 Dec 2019 15:27:14 -0500

> transport=ws is really invalid, is it?

It is not invalid, it just adds to overall confusion. This transport
parameter (and likely the whole route header) is irrelevant. This is why it
is a nit.
_____________
Roman Shpount