Subject: [Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03

From: Adrian Georgescu <[email-masked]>
Date: Wed, 22 Oct 2008 11:42:49 +0200

Hi Paul,

I believe Henry is heading into one direction only. The idea is to  
help developers implement the minimum necessary features in their User  
Agent and not biased towards a voice only application. The SIP end- 
points as describe by Henry would work with any service provider as  
long as they talk plain SIP. So 911 and voicemail and other services  
can be performed in the network as well, they are just another end- 
point.

If I were to develop a SIP UA today (which  I do actually) Henry's  
draft would be the starting point. I would definitely add MSRP to it,  
without relays as a minimum but adding relay extension is not that  
difficult, because any application that requires reliable or large  
data transport need a TCP media plane that SIP signalling or RTP does  
not provide. End-to-end encryption can also be realized on top of  
established MSRP session. File transfer and session based IM are  
applications that an end user would take for granted today and SIP  
lacks both.

Also the rich presence conflicts with the basic presence PIDF, I would  
go for rich presence even if the "richness" of the information is  
something that would be avoided due to its complexity in the  
presentation to end-user interface.

For the rest I would not do much changes to the draft.

Regards,
Adrian

Henry,

Based on this discussion, it now sounds like you are heading in *two*
directions:

- connecting to a SP that provides services (e.g. 911, maybe others,
    like voicemail, forwarding, ...)
    The SP in this case is largely looking for a "dumb" device and
    provides the services in the network. The "request for service"
    is then "tunneled" via simple services like invite, with the
    service request encoded in the AOR. (e.g. the "911", or "star"  
codes).
    In this case you are then competing with other profiles, such as
    SIPConnect or PacketCable.

- very low added value SP, that simple provides registration
    and routing. All services are provided by the UAs.

I'd like to see the goals spelled out better. Then we can discuss if
they are met.

	Thanks,
	Paul

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2008 10:52:25 -0400

Adrian Georgescu wrote:
> Hi Paul,
> 
> I believe Henry is heading into one direction only. The idea is to help 
> developers implement the minimum necessary features in their User Agent 
> and not biased towards a voice only application. The SIP end-points as 
> describe by Henry would work with any service provider as long as they 
> talk plain SIP. So 911 and voicemail and other services can be performed 
> in the network as well, they are just another end-point.

There is a huge difference between services implemented in the UA and 
services implemented in the network. Take for example emergency 
services. The typical implementation is simply for the UA to accept the 
dial string (e.g. 911) and put it into an INVITE. The UA most likely is 
treating this as any other call - not realizing it is an emergency call. 
Hence it doesn't apply special processing to it, that is supposed to be 
supplied, like refusing to disconnect the call on hangup. Also, it 
doesn't play any part in determining its location - depending on the 
network to be able to figure that out. The network may or may not be 
able to determine that.

In any case, each SP has its own requirements for what a device that 
connects to it must do to work with it. Perhaps it would be a useful 
thing to create a common spec for a UA that can work with "most" SPs. To 
do that it would probably be better to gather the specs from the SPs 
than to look at a few phone adapters. But I think a lot of SPs are not 
open to connection from devices they don't supply, so there may not be a 
lot of value in such a spec.

> If I were to develop a SIP UA today (which  I do actually) Henry's draft 
> would be the starting point. I would definitely add MSRP to it, without 
> relays as a minimum but adding relay extension is not that difficult, 
> because any application that requires reliable or large data transport 
> need a TCP media plane that SIP signalling or RTP does not provide. 
> End-to-end encryption can also be realized on top of established MSRP 
> session. File transfer and session based IM are applications that an end 
> user would take for granted today and SIP lacks both.

If I were to develop a UA today, I think I would figure out who I intend 
it to connect to, and find out what their requirements are. If somebody 
already has made a consolidated set of requirements that covers all 
those things I intend to talk to then that would be helpful to me.

That is what I am lacking in the present document. It doesn't tell me 
what its field of applicability is.

	Thanks,
	Paul

>    service request encoded in the AOR. (e.g. the "911", or "star" codes).

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 22 Oct 2008 18:12:16 +0200

On Oct 22, 2008, at 4:52 PM, Paul Kyzivat wrote:

>> help developers implement the minimum necessary features in their  
>> User Agent and not biased towards a voice only application. The SIP  
>> end-points as describe by Henry would work with any service  
>> provider as long as they talk plain SIP. So 911 and voicemail and  
>> other services can be performed in the network as well, they are  
>> just another end-point.
>
> There is a huge difference between services implemented in the UA  
> and services implemented in the network. Take for example emergency  
> services. The typical implementation is simply for the UA to accept  
> the dial string (e.g. 911) and put it into an INVITE. The UA most  
> likely is treating this as any other call - not realizing it is an  
> emergency call.

I can easily make the SIP UA give more priority and to that call  
rather than re-engineering the whole Internet to do something like  
that, can't I?

> Hence it doesn't apply special processing to it, that is supposed to  
> be supplied, like refusing to disconnect the call on hangup. Also,  
> it doesn't play any part in determining its location - depending on  
> the network to be able to figure that out. The network may or may  
> not be able to determine that.

Do you mean a network can better figure out where I am rather than  
myself? I highly doubt that I wish to let the network dispatch the  
ambulance to where they think I am rather than where I am actually (by  
my local GPS or AGPS device). Is up to me to convey location  
information and not to the network.

> thing to create a common spec for a UA that can work with "most"  
> SPs. To do that it would probably be better to gather the specs from  
> the SPs than to look at a few phone adapters. But I think a lot of  
> SPs are not open to connection from devices they don't supply, so  
> there may not be a lot of value in such a spec.
>>
> If I were to develop a UA today, I think I would figure out who I  
> intend it to connect to,

A SIP URI is a SIP URI. Do you make a distinction when you send an  
email what type of server software or type of recipient is behind the  
destination email address? Your email client works the same every  
time. This is why you use email and skype today instead of SIP. They  
do not make this distinction.

Why is this tendency with SIP to make it more complicated than it  
actually is?

Is not a personal question, I am just wondering because I am young and  
I was not around when SIP was invented.

Adrian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2008 12:30:57 -0400

Adrian Georgescu wrote:
>>> end-points as describe by Henry would work with any service provider 
>>> as long as they talk plain SIP. So 911 and voicemail and other 
>>> services can be performed in the network as well, they are just 
>>> another end-point.
>>
> I can easily make the SIP UA give more priority and to that call rather 
> than re-engineering the whole Internet to do something like that, can't I?

You can if you know which dial strings correspond to emergency services. 
But if you are defining a generic device to be deployed in a variety of 
places, with differing SPs, then how do you know that. You then start to 
create ambiguity about where the service is implemented - its part in 
the UA and part in the service. While that may be an appropriate thing 
to do, it further complicates the specification.

>> be supplied, like refusing to disconnect the call on hangup. Also, it 
> my local GPS or AGPS device). Is up to me to convey location information 
> and not to the network.

I mean that in this scenario it is the SP that has taken the responsibility.

If you want to do that (a good thing if you are able) then you need to 
implement all the specs related to that (which aren't a part of this 
list currently). And you need to be connected to the network in such a 
way that you can actually talk to the PSAP, or work cooperatively with 
the SP to do so.

The point is that the current list of specs don't support that.

>> thing to create a common spec for a UA that can work with "most" SPs. 
>> To do that it would probably be better to gather the specs from the 
>> SPs than to look at a few phone adapters. But I think a lot of SPs are 
>> not open to connection from devices they don't supply, so there may 
>> not be a lot of value in such a spec.
>>>
> A SIP URI is a SIP URI. Do you make a distinction when you send an email 
> what type of server software or type of recipient is behind the 
> destination email address? Your email client works the same every time. 
> This is why you use email and skype today instead of SIP. They do not 
> make this distinction.
> 

Certainly that is the ideal. We just aren't there yet.

The complexity is there because some people found a need for some 
functionality. Some of that in retrospect was a bad idea. Other things 
are indeed important to some people/environments but not so important to 
others.

The authors of this draft assert that a much smaller set of specs is 
"sufficient". But it won't be sufficient when interacting with somebody 
that requires one of the other specs. That's why it is still important 
to know your peer requires.

> Is not a personal question, I am just wondering because I am young and I 
> was not around when SIP was invented.

Like many things, sip started out "simple". But it was found to be 
insufficient in the simple form, so it was "fixed", and in the process 
became more complicated.

In some cases this complexity is unavoidable - the earlier simplicity 
was an illusion - sweeping things under the rug.

In other cases, the complexity is the result of evolution and the need 
for backward compatibility. And in some cases its just that things just 
weren't done as well as they might have been.

Most who have worked on sip for awhile would probably agree that if we 
could start over with a clean slate and all that we now know we could 
create something simpler and better. But there is too much investment in 
implementations of what we have, making a clean slate infeasible. We are 
stuck with what we can do in an evolutionary way.

	Thanks,
	Paul

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 22 Oct 2008 18:45:18 +0200

I believe most of us are actually on the same page which is:

-	if you consider a feature is necessary (for this profile) then
list all the documents needed to support that feature.

-	if a feature is not necessary (for this profile) then clearly
say that the set of documents identified will not support that feature.

Thus I seized on RFC 3966 earlier. Using that as an example, I have no
problem with the profile either including it or not, but if it is not
there, then clearly say that interworking with the PSTN will not be
possible, and that emergency calls using PSTN like numbers will be
impossible. 

Obviously various network providers will have their reasons for various
extensions being necessary and supported in their networks. Readers need
to be able to clearly identify the mismatch between what the profile
contains and what those operators think is needed. What those network
providers would call "plain SIP" would not be the same list as you would
use. The security requirements invariably differ.

Regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Georgescu
> Sent: Wednesday, October 22, 2008 10:43 AM
> To: [email-masked]
> Subject: [Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03
> 
> Hi Paul,
> 
> I believe Henry is heading into one direction only. The idea 
> is to help developers implement the minimum necessary 
> features in their User Agent and not biased towards a voice 
> only application. The SIP end- points as describe by Henry 
> would work with any service provider as long as they talk 
> plain SIP. So 911 and voicemail and other services can be 
> performed in the network as well, they are just another end- point.
> 
> If I were to develop a SIP UA today (which  I do actually) 
> Henry's draft would be the starting point. I would definitely 
> add MSRP to it, without relays as a minimum but adding relay 
> extension is not that difficult, because any application that 
> requires reliable or large data transport need a TCP media 
> plane that SIP signalling or RTP does not provide. End-to-end 
> encryption can also be realized on top of established MSRP 
> session. File transfer and session based IM are applications 
> that an end user would take for granted today and SIP lacks both.
> 
> Also the rich presence conflicts with the basic presence 
> PIDF, I would go for rich presence even if the "richness" of 
> the information is something that would be avoided due to its 
> complexity in the presentation to end-user interface.
> 
> I'd like to see the goals spelled out better. Then we can 
> discuss if they are met.
> 
> 	Thanks,
> 	Paul
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 22 Oct 2008 18:46:24 +0200

Thanks Paul

Now I understand why SIP became so complicated.

I am glad Henry could make it simple enough for me to get started :-)

Adrian

On Oct 22, 2008, at 6:30 PM, Paul Kyzivat wrote:

>>>> I believe Henry is heading into one direction only. The idea is  
>>>> to help developers implement the minimum necessary features in  
>>>> their User Agent and not biased towards a voice only application.  
>>>> The SIP end-points as describe by Henry would work with any  
>>>> service provider as long as they talk plain SIP. So 911 and  
>>>> voicemail and other services can be performed in the network as  
>>>> well, they are just another end-point.
>>>
>>> and services implemented in the network. Take for example  
>>> emergency services. The typical implementation is simply for the  
>>> UA to accept the dial string (e.g. 911) and put it into an INVITE.  
>>> The UA most likely is treating this as any other call - not  
>>> realizing it is an emergency call.
> You can if you know which dial strings correspond to emergency  
> services. But if you are defining a generic device to be deployed in  
> a variety of places, with differing SPs, then how do you know that.  
> You then start to create ambiguity about where the service is  
> implemented - its part in the UA and part in the service. While that  
> may be an appropriate thing to do, it further complicates the  
> specification.
>
>>> Hence it doesn't apply special processing to it, that is supposed  
>>> to be supplied, like refusing to disconnect the call on hangup.  
>>> Also, it doesn't play any part in determining its location -  
>>> depending on the network to be able to figure that out. The  
>>> network may or may not be able to determine that.
>> ambulance to where they think I am rather than where I am actually  
>> (by my local GPS or AGPS device). Is up to me to convey location  
> If you want to do that (a good thing if you are able) then you need  
> to implement all the specs related to that (which aren't a part of  
> this list currently). And you need to be connected to the network in  
> such a way that you can actually talk to the PSAP, or work  
> cooperatively with the SP to do so.
>
>>> In any case, each SP has its own requirements for what a device  
>>> that connects to it must do to work with it. Perhaps it would be a  
>>> useful thing to create a common spec for a UA that can work with  
>>> "most" SPs. To do that it would probably be better to gather the  
>>> specs from the SPs than to look at a few phone adapters. But I  
>>> think a lot of SPs are not open to connection from devices they  
>>> don't supply, so there may not be a lot of value in such a spec.
>>>>
>> email what type of server software or type of recipient is behind  
>> the destination email address? Your email client works the same  
>> every time. This is why you use email and skype today instead of  
>> SIP. They do not make this distinction.
> functionality. Some of that in retrospect was a bad idea. Other  
> things are indeed important to some people/environments but not so  
> important to others.
>
> "sufficient". But it won't be sufficient when interacting with  
> somebody that requires one of the other specs. That's why it is  
> still important to know your peer requires.
>
>> Is not a personal question, I am just wondering because I am young  
>> and I was not around when SIP was invented.
>
> insufficient in the simple form, so it was "fixed", and in the  
> process became more complicated.
>
> In some cases this complexity is unavoidable - the earlier  
> simplicity was an illusion - sweeping things under the rug.
>
> In other cases, the complexity is the result of evolution and the  
> need for backward compatibility. And in some cases its just that  
> things just weren't done as well as they might have been.
>
> Most who have worked on sip for awhile would probably agree that if  
> we could start over with a clean slate and all that we now know we  
> could create something simpler and better. But there is too much  
> investment in implementations of what we have, making a clean slate  
> infeasible. We are stuck with what we can do in an evolutionary way.
>
> 	Thanks,
> 	Paul
>
>> Adrian

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 22 Oct 2008 19:18:51 +0200

Hi,
 
I agree with Paul.
 
Normally, when you put together a list of RFCs etc that you need to support/implement, you do that based on REQUIREMENTS.
 
The requirements may be specified for a typical network architecture (IMS for example), and/or requirements specified by a customer.
 
So, I think it should be clearly written what requirements the spec is trying to solve (we do that with all SIP specs nowadays, don't we?). If we're just trying to come up with a good list of RFCs based on "taste", many people may have different opinions on what it should contain...
 
In addition, in my opinon the draft defines a PROFILE.
 
Regards,
 
Christer

________________________________

From: [email-masked] on behalf of Paul Kyzivat
Sent: Wed 22/10/2008 16:52
To: Adrian Georgescu
Cc: [email-masked]
Subject: Re: [Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03

        Thanks,
        Paul

---

From: Alan Johnston <[email-masked]>
Date: Wed, 22 Oct 2008 12:44:08 -0500

I've been holding off wading into this discussion to see where it goes.  
As it has really gone off track, I'll put in my views.

Firstly, this is *not* a profile of SIP - this document doesn't say you 
don't have to support parts of RFC 3261.  However, it is, perhaps, a 
profile of the entire set of SIP extensions.  As such, it is a valuable 
counterweight to the Hitchhikers guide which is a frightening expose of 
the kitchen sink of extensions we have developed over the years.

And as for the requirements being clear, I think they are, but perhaps 
many people just can't get their heads around them.  Only use servers 
for rendezvous functionality, and that's it.  Period.  What part of this 
isn't clear?  I know it doesn't fit with the current service 
provider/research focus that is what drives us today in RAI.  And if 
this is your focus, you can ignore the document and go back to your day job.

I think that many people will applaud and understand this draft, but 
those people aren't the ones who post on the RAI lists every day.  They 
are the poor implementors who are trying to get by and interoperate 
given the mess we have created.

Thanks,
Alan

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 22 Oct 2008 20:08:15 +0200

Hi,

>profile of the entire set of SIP extensions.
 
I agree. It's a high level profile. In order to ensure interoperability you would need to go more into the details, talking about what parts of the listed RFCs need to be supported, and HOW they need to be supported (use-cases etc).
 
>As such, it is a valuable counterweight to the Hitchhikers guide which is a frightening expose of the kitchen sink of extensions we have developed over the years.

Fair enough, but then that should be clearly indicated in the beginning of the draft.

>this is your focus, you can ignore the document and go back to your day job.

Eventhough the document may not fit into the architectures I am working on, my general opinion is that profiles are important indegrients for interoperability (as I also indicated at the SIPForum workshop in Chicago).

And, even if you only use servers for rendezvoud functionality, I still think there are a number of additional drafts which would "qualify".

I am also sure there are other media security mechanisms that the one you have listed which would fit.

BUT, if the purpose of this document is to simply say "Hey, this is what we have done", then fine - then you don't need any further requirements. 

>given the mess we have created.

I have never said I don't like the draft. I think it's a good initiative, which I have also told Henry off-line. 

But, based on experience I know that it is always helpful to know exactly what the intention of a draft is - and make sure that others also know it.

Regards,

Christer

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 22 Oct 2008 20:09:28 +0200

> infeasible. We are stuck with what we can do in an evolutionary way.

I wish we do not have to be stuck in the infinite complexity created  
by our past mistakes. Unless you are talking about some terminal  
desease or the like you can always fix a bad decision your took in the  
past with a good decision you take now.

Or to quote from a book I read  "Any mistakes you commit through  
audacity are easily corrected with more audacity". Don't know who  
wrote this.

Adrian

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 22 Oct 2008 20:13:39 +0200

Going to another organisation for a definition of profile (ETS 300 406
but I believe it is consistent with ISO 9646):

"A profile identifies a consistent set of chosen options from a base
specification or from a set of base
specifications, in order to provide a given function in a given
environment.
By restricting choices among the options available in the base
specifications, a profile increases the
probability that systems will interoperate, i.e. perform together the
given function to which the profile is
aimed at.
The base specifications upon which a profile is based are called
components of this profile."

What you have is a profile.

What needs to be clear is when that profile is useful to a reader, and
when it merely provides a chocolate teapot. Paul is saying that and I
agree with him. Noone is saying that the profile you have provided is
not useful. 

Regards

Keith

> [mailto:[email-masked]] On Behalf Of Alan Johnston
> Sent: Wednesday, October 22, 2008 6:44 PM
> To: Christer Holmberg
> Cc: [email-masked]; Paul Kyzivat
> Firstly, this is *not* a profile of SIP - this document 
> doesn't say you don't have to support parts of RFC 3261.  
> However, it is, perhaps, a profile of the entire set of SIP 
> extensions.  As such, it is a valuable counterweight to the 
> Hitchhikers guide which is a frightening expose of the 
> kitchen sink of extensions we have developed over the years.
> 
> And as for the requirements being clear, I think they are, 
> but perhaps many people just can't get their heads around 
> them.  Only use servers for rendezvous functionality, and 
> that's it.  Period.  What part of this isn't clear?  I know 
> it doesn't fit with the current service provider/research 
> focus that is what drives us today in RAI.  And if this is 
> your focus, you can ignore the document and go back to your day job.
> 
> I think that many people will applaud and understand this 
> draft, but those people aren't the ones who post on the RAI 
> lists every day.  They are the poor implementors who are 
> trying to get by and interoperate given the mess we have created.
> 
> Thanks,
> Alan
> 
> Christer Holmberg wrote:
> > Hi,
> >  
> > I agree with Paul.
> >  
> > Normally, when you put together a list of RFCs etc that you 
> need to support/implement, you do that based on REQUIREMENTS.
> >  
> > The requirements may be specified for a typical network 
> architecture (IMS for example), and/or requirements specified 
> by a customer.
> >  
> > So, I think it should be clearly written what requirements 
> the spec is trying to solve (we do that with all SIP specs 
> nowadays, don't we?). If we're just trying to come up with a 
> good list of RFCs based on "taste", many people may have 
> different opinions on what it should contain...
> >  
> >> services can be performed in the network as well, they are 
> just another end-point.
> >>     
> >
> > likely is treating this as any other call - not realizing 
> it is an emergency call.
> >> data transport need a TCP media plane that SIP signalling 
> or RTP does not provide.
> >> session. File transfer and session based IM are 
> applications that an 
> >> end user would take for granted today and SIP lacks both.
> >>     
> >
> > intend it to connect to, and find out what their 
> requirements are. If 
> > somebody already has made a consolidated set of requirements that 
> > covers all those things I intend to talk to then that would 
> be helpful to me.
> >
> >> Also the rich presence conflicts with the basic presence PIDF, I 
> >> would go for rich presence even if the "richness" of the 
> information 
> >> is something that would be avoided due to its complexity in the 
> discuss if 
> >> This list is for NEW development of the application of SIP Use 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments of core SIP
> >>
> >>     
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> >
> >
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> >
> >
> >   
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 22 Oct 2008 20:20:42 +0200

As soon as you let a committee near any subject, you will invariably get
complication. Every protocol I have worked on in standards bodies has
invariably got more complicated. Two years after commencement someone
comes in with a xxx-LITE version, which if it ever starts grows even
more heavyweight that the original before being abandoned.

The only programming language I have seen that pretty much managed to do
away with all options was Pascal - designed by one person and then
imposed on the world by force of personality.

Dean would like to go to SIP 3.0 and do the same thing, but
unfortunately the world is not listening, and are busy developing SIP
2.0 instead.

Regards

Keith

> Sent: Wednesday, October 22, 2008 7:09 PM
> To: Paul Kyzivat
> Cc: [email-masked]
> > create something simpler and better. But there is too much 
> investment 
> > in implementations of what we have, making a clean slate 
> infeasible. 
> > We are stuck with what we can do in an evolutionary way.
> 
> I wish we do not have to be stuck in the infinite complexity 
> created by our past mistakes. Unless you are talking about 
> some terminal desease or the like you can always fix a bad 
> decision your took in the past with a good decision you take now.
> 
> Or to quote from a book I read  "Any mistakes you commit 
> through audacity are easily corrected with more audacity". 
> Don't know who wrote this.
> 
> Adrian
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2008 14:35:49 -0400

I must say, I believe Christer, Keith, and I are all on exactly the same 
page. Amazing! (I can't remember any other time for that.)

Alan says:

> that's it.  Period.  What part of this isn't clear?  

Actually I thought it was reasonably clear when I did my initial review. 
(Aside from the issue of PSTN interconnect, which also seemed to be in 
scope, using some other sort of server.) Its become less clear to me in 
the subsequent discussion, especially based on some of the comments from 
Eunsoo.

But what *wasn't* clear is what it is expected that these UAs will be 
able to *do* when they have rendezvoused, using this set of specifications.

I might actually understand this better if it were billed as a "primer" 
to the hitchhikers guide: a suggestion of what to learn first if you are 
trying to get started as a sip implementor.

But rather it seems to be billed as "this should be all you need to 
know", and it that case I really want to know "all I need to know to do 
XYZ".

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2008 14:40:13 -0400

Adrian Georgescu wrote:
>> create something simpler and better. But there is too much investment 
>> in implementations of what we have, making a clean slate infeasible. 
> I wish we do not have to be stuck in the infinite complexity created by 
> our past mistakes. Unless you are talking about some terminal desease or 
> the like you can always fix a bad decision your took in the past with a 
> good decision you take now.

Yes and no. You can always create a new way to do something that is 
better than the old way, rendering the old way obsolete. But as long as 
there is the possibility that you might have to interact with somebody 
that only implemented the old way, you have to be prepared for that 
eventuality. Hence the complexity just goes up.

A bunch of people spent several years defining SDPng - a replacement for 
SDP that intended to remedy all of its limitations. Eventually the whole 
effort was dropped, largely (IMO) because the pain of migrating to it 
exceeded the benefit of doing so.

	Thanks,
	Paul

> audacity are easily corrected with more audacity". Don't know who wrote 
> this.
> 
> Adrian
>

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 22 Oct 2008 16:05:09 -0500

> But as long as 
> that only implemented the old way,

This is another good point that I believe we have to write down.
Simple SIP is not meant to interoperate with all the telephony features for
which 100 flavors of SS7 have been deployed (there were ~100 the last time I
looked). RFC4485  states very clearly SIP is not a replacement for the PSTN.
If you don't agree with RFC4485 "Guidelines for SIP Authors" just say so.
Our simple SIP is rather the KISS Internet approach.

It seemed to us the section of what is out of scope was clear enough, but
this discussion is helpful.

The authors have stated clearly the main usage scenario for the simple SIP
_alternative_ is for SIP as a Rich Internet Application and also for P2P SIP
where everything is in the endpoints. Finally, SIP can re-join the web!
(That's where it started around 1996 and what made it successful IMO).

This does not preclude a few simple servers such as voice mail. But as you
Paul have pointed out, interoperability with the PSTN is left to SIP-PSTN
gateways. This was the other good point you made.

Also, to preclude any misunderstandings, simple SIP is out of scope for all
the SIP extensions meant to contradict the spirit of RFC 4485.
"Legacy SIP" (yes we have arrived here) that is intended to emulate the
PSTN, private extensions to accommodate various business models is also out
of scope. As mentioned, we aim to use SIP just as a a reasonably simple
_Internet_ protocol, working best in the e2e (different from p2p) model and
simple CS model for rendezvous and maybe some other plain functions such as
voice mail storage.

Now thinking about voice mail, why not place it in some cloud computing?
Why does one need dedicated feature servers and not move the features into
the cloud, if you don't like the endpoints (SIP UA)?
But this is for another day. Let's enjoy simple SIP for now.

Henry

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 22 Oct 2008 16:12:50 -0500

Keith,

Sorry to repeat: The SIP UA can call any emergency SIP URI such as SOS or
dial 911 through a PSTN gateway. Is this clear enough?

Needless to point out that using the Internet for emergency and avoiding 911
will also support life saving data such as medical vital signs, location
(GPS & mobile triangulation) and video.

Henry

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2008 18:13:05 -0400

> dial 911 through a PSTN gateway. Is this clear enough?

I'm pretty sure that the emergency services experts will tell you that 
"dial 911 through a PSTN gateway" is not an acceptable implementation. 
It won't provide the location information (at least not without a lot of 
other configuration), among other things.

Nor will calling an emergency SIP URI (urn:service:sos I think) work 
unless you have some server in the network that provides the service of 
routing that to the right place. Again you will need location info, etc. 
to make this work. IOW, stuff that currently isn't part of sip-tools.

> (GPS & mobile triangulation) and video.

If you do the long list of stuff required to make this all work, which 
requires stuff not in sip-tools.

If you intend for emergency services calls to be among the things that 
you can do with sip-tools, then call it out and somebody will verify if 
you have specified everything needed to make it work. But if we don't 
know that is in scope then we can't do that.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2008 18:14:32 -0400

> Our simple SIP is rather the KISS Internet approach.

Leave the legacy telephony things out of it. Is this intended to define 
a *new* "walled garden" of things that can talk to one another using 
this set of specs but perhaps not to other things? Is it expected to 
interoperate with devices that implemented 2543, or some other subset of 
the specs you call out?

What about devices that implement richer, but different sets of sip 
specs? Somebody might implement IM using MSRP, and not be able to 
interoperate with a device following sip-toos recommendatations because 
that uses MESSAGE. Since there is currently no requirement that those 
implementing MSRP also implement MESSAGE, this could be a problem even 
among devices that support "IM".

> gateways. This was the other good point you made.

Its one thing to define this bounded world so that it excludes PSTN. 
There are certainly valid use cases for that.

Its another thing if you then intend to open it up to the PSTN via 
gateways. Then, to get any interop you will get all tied up in knots 
about how phone numbers are encoded as URLs, etc.

> PSTN,

I'm certain we have many flavors of legacy SIP. But I think I would 
leave that terminology for sip usages that were considered appropriate 
in the past, but that are no longer considered appropriate. For 
instance, 2543 implementations and some uses of INFO. Some past attempts 
to use MESSAGE for IM sessions might also fall into that category. (But 
they may better be simply considered proprietary.)

I take your point about attempts to replicate the PSTN via SIP, but I 
think that deserves some other sort of name. Some of that is *bad* and 
some of it is *good*. And if you get 10 people together to discuss it I 
expect you will get at least 20 different opinions of which parts are 
good and which are bad.

The fact that you mention PSTN gateways as perhaps fitting into systems 
based on these sip-tools suggests to me that you think communicating 
with the PSTN via sip isn't all bad. For better or worse, there are 
billions of devices out there that can be reached that way and no other.

So then it becomes a matter of where you draw the line. Do you want a 
device that is implemented via sip-tools specs to be able to have a 
phone number as its AOR, and be reached from those billions of PSTN 
devices? Many will consider that to be a desirable thing. But it seems 
to come with a bunch of regulatory strings attached.

> private extensions to accommodate various business models is also out

> the cloud, if you don't like the endpoints (SIP UA)?

I'm sure there are interesting possibilities there, but they need to be 
specified if they are to be interoperable.

IMO the most basic "network" feature after rendezvous is for something 
useful to happen if there is no registered device to rendezvous with. 
Voicemail is one possibility, forwarding, redirecting are others. The 
possibilities are endless. One of my favorite concepts is for the home 
proxy to return a 3xx with an html or mail URL if there are no sip 
contacts registered. But that isn't useful unless the callers are 
prepared to do something meaningful when they get such a response. 
(E.g., locally record a voice/video message and email it to the returned 
mail address.)

In *theory* such behavior is covered by a UA that implements to 
sip-tools. But in practice there needs to be something that describes 
that behavior.

	Thanks,
	Paul

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 23 Oct 2008 03:03:33 +0200

Yes, I was aware that you were going make that clear in the
specification. I was just using that RFC number as an example of the
impact of either inclusion or no inclusion - thus demonstrating a more
general point. 

Regards

Keith

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Wednesday, October 22, 2008 10:13 PM
> To: DRAGE, Keith (Keith); [email-masked]
> Sorry to repeat: The SIP UA can call any emergency SIP URI 
> such as SOS or dial 911 through a PSTN gateway. Is this clear enough?
> 
> Needless to point out that using the Internet for emergency 
> and avoiding 911 will also support life saving data such as 
> medical vital signs, location (GPS & mobile triangulation) and video.
> 
> Henry
> 
> 
> > - if you consider a feature is necessary (for this profile) 
> then list 
> > all the documents needed to support that feature.
> > 
> > - if a feature is not necessary (for this profile) then clearly say 
> > that the set of documents identified will not support that feature.
> > 
> > Obviously various network providers will have their reasons for 
> > various extensions being necessary and supported in their networks. 
> > Readers need to be able to clearly identify the mismatch 
> between what 
> > the profile contains and what those operators think is needed. What 
> > those network providers would call "plain SIP" would not be 
> the same 
> > list as you would use. The security requirements invariably differ.
> > 
> > Regards
> > 
> > Keith
> > 
> >> end- points as describe by Henry would work with any 
> service provider 
> >> another end- point.
> or RTP does

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Oct 2008 21:15:05 -0700

> Our simple SIP is rather the KISS Internet approach.

Making it clear what can and cannot be done (based on real implementations) would be quite worthwhile.  Naturally, such an approach may not work for everyone or in every scenario.  But if it can cover suitably large fraction of real-world deployments, and assist in focusing interoperability efforts on the core functionality identified, that would be an important contribution. 

> this set of specs but perhaps not to other things? 

I would hope not.  

> Support for E911 is in practice very important. 

I'd certainly agree -- but it's not yet clear to me how important *SIP* support for that will be in practice. 
For example, in my small medical office deployment with wired handsets, we are planning to route E911 calls to the provider, who has agreed to put location info into the ALI for the DIDs that they assign.  Obviously this won't handle Mobile handsets -- but all the customer mobile handsets run cellular technologies that support 911 anyway.  The likelihood that they will have any pure VoWLAN or WiMAX/VOIP handsets in the near (or even distant future) is slim to none. 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP