Subject: [dispatch] SIP Problem Statement

From: "Anton Tveretin" <[email-masked]>
Date: Mon, 26 Aug 2013 00:07:02 +0600

Hello All,
Maybe this is wrong WG (sipcore would be better). But I have some notes on 
SIP (and VoIP in general) future development. At least I want that.
I dare even to say that telephone wasn't invented by Bell; it is uninvented 
yet. ;)

1. Support for call pick-up, and other remote call control (remote call 
rejection, remote answering).
 Note: I am working on an I-D for this (over 25 years...). I suggest a new 
method, PICKUP.
One more note: call pick-up is specified for H.323 (H.450.5), and DPNSS1 
defines all remote call control.
2. Easy conferences without any supporting infrastructure, similar to H.323, 
as opposed to RFC 4575etc.
No way to join a SIP conference in the same way as H.323.
Note: may require to normatively update existing RFCs.
3. Standard call management codes, as GSM USSD.
4. Tons of headers, with arbitrary grouping of parameters (see my earlier 
post on From: and To:), and redundancy.
Example: transaction-id in Via: header and a pair of dialog-id, CSeq, which 
also uniquely indentifies a transaction.
5. Overload of INVITE with much potentially unused data (e.g. Caller-name 
when it is not displayed).
The same is true for SS7 and H.323.
Proposed solution: inquire some data only when needed; specify an 
Info-package for this.
6. D-channel bearer equivalent. I guess it is really undesired. Or, specify 
an Info-package.
7. True P2P (no infrastructure). Based on IP multicast.This is out of scope 
of current P2PSIP WG.

Any comments? Clearly, 4 is for next versions of SIP (if ever), maybe 6G 
(tm).

Sincerely yours,
Anton

---

From: Mary Barnes <[email-masked]>
Date: Mon, 26 Aug 2013 16:14:37 -0500

Generally, new works should be run through the DISPATCH WG.  I have a few
comments about some of your suggestions below [MB].

While we don't explicitly require drafts for topics, we do REQUIRE a clear
problem state and motivation for doing any new work.  Some of your
suggestions jump right into solutions, so it's not possible to discern the
real problem you are intending to solve with each of your suggestions.
You might consider writing some drafts.

Also, you should do a bit of homework - googling ietf and sip along with
some of your desired features will lead you to past work.  It's really
important you look at that to understand why you are unlikely to get some
of your proposals accepted or why there just won't be enough momentum for
IETF to take on the work.

Regards,
Mary
DISPATCH WG co-chair

On Sun, Aug 25, 2013 at 1:07 PM, Anton Tveretin <[email-masked]> wrote:

> I dare even to say that telephone wasn't invented by Bell; it is
> uninvented yet. ;)
>
[MB]  There have been proposals for call park and call pickup. You can see
here why the work was not progressed:
http://www.ietf.org/mail-archive/web/bliss/current/msg01107.html
Also, Google ietf sip remote call control.  There are a number of proposal
in the past for remote call control.  We've never had success in getting
the proposals agreed for a variety of reasons.  It's also important to note
that equivalency with H.323 was never a core requirement for SIP protocol
development.  You might want to look at the work in IMTC where they have a
profile for SIP that supports some of the h.323 functionality.  They sent a
liaison statement in the past.

2. Easy conferences without any supporting infrastructure, similar to
> H.323, as opposed to RFC 4575etc.
[MB] It's not at all clear to me what functionality you are asking for.
[/MB]

> 3. Standard call management codes, as GSM USSD.
[MB] I have no idea what you mean here.  [/MB]

> Example: transaction-id in Via: header and a pair of dialog-id, CSeq,
> which also uniquely indentifies a transaction

> Proposed solution: inquire some data only when needed; specify an
[MB] Again, we would need more details.  I think you are suggested we
should make some mandatory headers optional.  If that's what you're looking
for, then you need to provide ALOT of motivation. [/MB]

> 7. True P2P (no infrastructure). Based on IP multicast.This is out of
> scope of current P2PSIP WG.

> ______________________________**_________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dispatch<https://www.ietf.org/mailman/listinfo/dispatch>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Aug 2013 12:32:06 -0400

Where was this originally posted? (I don't think I got the original 
post, only this reply.)

Anton, I'm one of the chairs of SIPCORE. I agree that something like 
this should be first discussed on dispatch.

I won't go into the details of your message at this time, because there 
are meta-questions to address first.

I'd like to understand in general why you are posting this, and what 
sort of outcome you are expecting. What you seem to be suggesting sounds 
like a replacement, or a totally new version, of sip. People from time 
to time have expressed a wish to do a sip 3.0 that could fix many 
problems that are known with sip. But nobody talks about it very long, 
because pretty much everybody involved recognizes that there is no way 
to justify the work, or for such a think to be deployed if it were done.

If you want to consider something new and different, then I suggest you 
look into WebRTC/RTCWEB.

OTOH, if you have in mind incremental, backward compatible, changes to 
SIP, then I suggest you take out the stuff that doesn't fit that model.

	Thanks,
	Paul

On 8/26/13 5:14 PM, Mary Barnes wrote:
> Generally, new works should be run through the DISPATCH WG.  I have a
> few comments about some of your suggestions below [MB].
>
> While we don't explicitly require drafts for topics, we do REQUIRE a
> clear problem state and motivation for doing any new work.  Some of your
> suggestions jump right into solutions, so it's not possible to discern
> the real problem you are intending to solve with each of your
> suggestions.   You might consider writing some drafts.
>
> important you look at that to understand why you are unlikely to get
> some of your proposals accepted or why there just won't be enough
> momentum for IETF to take on the work.
> Regards,
> Mary
> DISPATCH WG co-chair
>
>
> On Sun, Aug 25, 2013 at 1:07 PM, Anton Tveretin <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hello All,
>     Maybe this is wrong WG (sipcore would be better). But I have some
>     notes on SIP (and VoIP in general) future development. At least I
>     want that.
>     1. Support for call pick-up, and other remote call control (remote
>     call rejection, remote answering).
>     Note: I am working on an I-D for this (over 25 years...). I suggest
>     a new method, PICKUP.
>     One more note: call pick-up is specified for H.323 (H.450.5), and
>     DPNSS1 defines all remote call control.
>
> [MB]  There have been proposals for call park and call pickup. You can
> see here why the work was not progressed:
> Also, Google ietf sip remote call control.  There are a number of
> proposal in the past for remote call control.  We've never had success
> in getting the proposals agreed for a variety of reasons.  It's also
> important to note that equivalency with H.323 was never a core
> requirement for SIP protocol development.  You might want to look at the
> work in IMTC where they have a profile for SIP that supports some of the
> h.323 functionality.  They sent a liaison statement in the past.
>
>     2. Easy conferences without any supporting infrastructure, similar
>     to H.323, as opposed to RFC 4575etc.
>     4. Tons of headers, with arbitrary grouping of parameters (see my
>     earlier post on From: and To:), and redundancy.
>     Example: transaction-id in Via: header and a pair of dialog-id,
>     CSeq, which also uniquely indentifies a transaction
>
>     5. Overload of INVITE with much potentially unused data (e.g.
>     Caller-name when it is not displayed).
> should make some mandatory headers optional.  If that's what you're
> looking for, then you need to provide ALOT of motivation. [/MB]
>
>     6. D-channel bearer equivalent. I guess it is really undesired. Or,
>     specify an Info-package.
>
>     7. True P2P (no infrastructure). Based on IP multicast.This is out
>     of scope of current P2PSIP WG.
>
>
>     Any comments? Clearly, 4 is for next versions of SIP (if ever),
>     maybe 6G (tm).
>
>     Sincerely yours,
>     Anton
>
>     _________________________________________________
>     dispatch mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/dispatch
>     <https://www.ietf.org/mailman/listinfo/dispatch>
>
>
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 27 Aug 2013 11:37:10 -0500

On Tue, Aug 27, 2013 at 11:32 AM, Paul Kyzivat <[email-masked]>wrote:

> Where was this originally posted? (I don't think I got the original post,
> only this reply.)
>
[MB] It was posted to the DISPATCH WG mailing list two days ago (you may
need to check your spam filters on your mit account as this doesn't seem
the first time you've missed some email ;)
http://www.ietf.org/mail-archive/web/dispatch/current/msg05017.html
[/MB]

>
> Anton, I'm one of the chairs of SIPCORE. I agree that something like this
> should be first discussed on dispatch.
>
> I'd like to understand in general why you are posting this, and what sort
> of outcome you are expecting. What you seem to be suggesting sounds like a
> replacement, or a totally new version, of sip. People from time to time
> have expressed a wish to do a sip 3.0 that could fix many problems that are
> known with sip. But nobody talks about it very long, because pretty much
> everybody involved recognizes that there is no way to justify the work, or
> for such a think to be deployed if it were done.
>
>> http://www.ietf.org/mail-**archive/web/bliss/current/**msg01107.html<http://www.ietf.org/mail-archive/web/bliss/current/msg01107.html>
>>     ______________________________**___________________
>>     dispatch mailing list
>>     https://www.ietf.org/mailman/_**_listinfo/dispatch<https://www.ietf.org/mailman/__listinfo/dispatch>
>>     <https://www.ietf.org/mailman/**listinfo/dispatch<https://www.ietf.org/mailman/listinfo/dispatch>
>> >
>>
>>
>>
>>
>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 27 Aug 2013 17:22:32 +0000

I'd like to endorse the comments from Paul and Mary.

Some of these issues would need an entirely new protocol. I do concur with those issues, and anyone involved in telephony protocols in ITU would have clearly pointed out these problems - however they were not present at that early date. However I'm not seeing a marketplace for a one-for-one replacement for SIP at the moment.

As regards other stuff, generally do bear in mind that while SIP has forced to become the carryall for pretty much everything, the IETF principle is to split functionality between protocols on the basis that "small is beautiful". That was the part of the basis for carving out the conference stuff as a separate protocol. Identify the problem, but do not necessarily present it as if SIP was the only solution.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: 27 August 2013 17:32
> To: [email-masked]
> Subject: Re: [dispatch] SIP Problem Statement
>