RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

["Henry Sinnreich" <[e-mail]>]

Mike,

>It is a backward compatibility issue to be able to interoperate with the
PSTN.  
>If we ever expect SIP to become dominant we need to overcome that entropy.

This statement was the object of many arguments on the list and not everyone
agrees with it. Actually, if I remember well, a chair person stated an
opposing view and it was also clearly stated in recent Internet Drafts.

Can someone recall what it was that "SIP services are not an emulation of
the PSTN"?

Sorry, but this ghost seems to come up more frequent than Halloween.

Thanks, Henry


 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Michael Hammer (mhammer)
Sent: Tuesday, October 11, 2005 9:18 AM
To: Paul Kyzivat (pkyzivat); Elwell, John
Cc: sipping
Subject: RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

Paul, John,

We like to say that SIP can be feature agnostic, but if we can't do a
feature that is widely used, then that is a problem.  So, I think the
real question is not what must be supported, but how it is to be
supported.

Although the features in the PSTN are fairly well understood, in many
cases they are just describing desired behaviors of the call
(forwarding) based on the state of users at the time the call arrives
(not registered, no answer, busy).  I don't think those are unique to
the PSTN as SIP users can be in the same basic states.  It only gets
complicated when SIP can produce more possible states.  So, I think the
issue here is not so much defining features as it is reacting to state
in the SIP network and documenting that state in the signaling.

It is a backward compatibility issue to be able to interoperate with the
PSTN.  If we ever expect SIP to become dominant we need to overcome that
entropy.  I think that is a burden we will just have to bear.  It is
also a backward compatibility issue to work with various generations of
SIP devices.  that is another fact of life we have to deal with.

I personally like the idea of keeping the redirection reason tied to the
redirecting URI added to the History-Info stack, but that doesn't help
those UACs that don't understand History-Info.  In the end, the perfect
may be the enemy of the good.  Hopefully, we can converge quickly on an
answer.

Mike



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