Subject: Re: [dispatch] draft-resske-dispatch-reason-loc-q850-00

From: Anton Tveretin <[email-masked]>
Date: Mon, 20 Mar 2017 01:38:31 +0500

Hello All,
Currently, this I-D gives an impression that SS7 is the only telephony, and SIP by itself is some useless crap :)
Terms "private network", "local", "remote" etc. are clearly applicable to SIP networks. So I suggest:
1. Explain these terms somewhere in the I-D rather than just refer to ITU. Note somewhat "these terms are consistent with Q.850".
2. Remove all references to the ITU from the abstract.
BTW my own I-Ds suffered from similar problem, interworking first, then SIP-only.
Regards,
Anton.

---

From: "Belling, Thomas (Nokia - DE/Munich)" <[email-masked]>
Date: Mon, 20 Mar 2017 09:34:03 +0000

Dear Anton,

Why would you remove ITU from the abstract?
The intention is only to encapsulate the ISUP cause location, and this should be clearly stated in the abstract.
And ISUP is defined by ITU-T ...
I would not expect that SIP clients send this, only IWFs.
But we still need to achieve that the semantics are clear.

Regards, Thomas

-----Original Message-----
From: Anton Tveretin [mailto:[email-masked]] 
Sent: Sunday, March 19, 2017 9:39 PM
To: DISPATCH list <[email-masked]>; [email-masked]; Belling, Thomas (Nokia - DE/Munich) <[email-masked]>
Subject: Re: draft-resske-dispatch-reason-loc-q850-00

Hello All,
Currently, this I-D gives an impression that SS7 is the only telephony, and SIP by itself is some useless crap :) Terms "private network", "local", "remote" etc. are clearly applicable to SIP networks. So I suggest:
1. Explain these terms somewhere in the I-D rather than just refer to ITU. Note somewhat "these terms are consistent with Q.850".
2. Remove all references to the ITU from the abstract.
BTW my own I-Ds suffered from similar problem, interworking first, then SIP-only.
Regards,
Anton.

---

From: Anton Tveretin <[email-masked]>
Date: Thu, 30 Mar 2017 23:33:25 +0500

Dear Thomas,
I do not agree with you.
SIP UA is always a device that belongs to somebody. So it is in either in a public network (licensed), or in a private network, or user equipment.
SIP clients would benefit from tracking error. For example, busy or congestion signal (486/600) might come from the called user, from her network, from a transit network (so retrying the call may succeed, if another transit network is chosen), or from caller's network (so all calls might fail).
Adding features to SIP just for interworking sounds a little weird. We believe that SIP will at once replace SS7, don't we?
Regards, Anton