Subject: RE: [Sip] Default value for Timer C (was #282)

From: "Chiou, Mark" <[email-masked]>
Date: Tue, 8 Jan 2002 13:07:20 -0600

I agree this is not a PSTN, but don't forget the whole world is not all
IP yet.
Please think about Cellular networks as an example, there are still a
large portion of the calls interworking with PSTN networks. The same
scenario will be occurred for IP. We CANNOT exclude the legacy networks
at all.

A penny worth thought,

Mark Chiou
Santera 

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]]
Sent: Tuesday, January 08, 2002 12:36 PM
To: [email-masked]; 'Robert Sparks'; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sip] Default value for Timer C (was #282)

> Everyone please
> inhale deeply, exhale slowly, and repeat to yourself: "This is not
> the PSTN. This is not the PSTN. This is not the PSTN."

Yesss!!!

Henry Sinnreich
WorldCom

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, January 08, 2002 11:20 AM
> To: 'Robert Sparks'; [email-masked];
[email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [Sip] Default value for Timer C (was #282)
> 
> I know I'm entering this thread late (I'm a bit behind on the list),
> but I just *need* to object.
> 
> In particular, if we accept Robert's concession, this consensus makes
> the 182 status code almost completely worthless.
> 
> This *isn't* a TDM architecture, and treating it as such is
ridiculous.
> I was under the impression that everyone here understood that billing
> based on SIP signaling is a rather ridiculous proposition; given that,
> it should be obvious that remaining in a pre-answer state isn't any
sort
> of an attempt to "cheat." It's obviously someone using the basic
building
> blocks of SIP in a way that you may not have conceived in order to
> provide some service -- and I thought that's what the protocol was all
> about.
> 
> Staying in a pre-answer state has several legitimate uses. Sending of
> 182 messages is one of the most obvious ("SIP/2.0 182 Call is queued;
> approximate wait is 13 minutes"), since it is endorsed by the
> specification itself. Robert has pointed out another real-world
> application (which happens to involve legacy systems).
> 
> So, there's the theoretical problem to satisfy the purists, and
> the actual "someone you know has personally been inconvenienced
> by this" problem to satisfy those swayed by anecdotes: an arbitrary
> short limit on pre-answer states creates a real problem.
> 
> There have already been proposals about how to work around this (e.g.
> re-sending provisional responses periodically), so I don't believe the
> impasse is technical in nature.
> 
> That means we have a philosophical difference here. Everyone please
> inhale deeply, exhale slowly, and repeat to yourself: "This is not
> the PSTN. This is not the PSTN. This is not the PSTN." Then examine
> the problem from a SIP perspective. Keep the whole "generality" thing
> in mind, and consider whether you want to limit the number of services
> and the ways they can be implemented.
> 
> /a
> 
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

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

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

---

From: [email-masked]
Date: Tue, 8 Jan 2002 13:47:09 -0600

You are absolutely correct: interworking will exist for quite some
time now.

If you look over the ISUP interworking draft that Gonzalo, Jon, Lyndon, 
and I wrote, you'll see that we address this. In fact, we don't solve
it; ISUP does -- we just point out the obvious solution. If you'll examine
at the way that Q.767 T7 and T11 work, and analyze the implications for
SIP interworking, you'll see that the ISUP network, if necessary, will
tear down the call, and that PSTN gateways have mechanisms (early-ACM
messages) to avert such teardowns. It's all handled on the PSTN side,
and needs no provision in the SIP protocol. And that's the way it
needs to be.

You're always going to have interworking points between networks, and
it's their job to provide appropriate "impedance matching" between
the networks. We can't take every feature of CAS, ISDN, ISUP, national
TUP variants, etc., etc., and add them to SIP in exactly the same way
that they work in their native networks. The vagaries of these protocol
variations are, by definition, protocol-specific issues. They should be
adapted by correctly designed interworking points, not by forcing the
round peg of SIP into the variously shaped holes of the myriad PSTN
protocols.

/a

> From: Chiou, Mark [mailto:[email-masked]]
> Sent: Tuesday, January 08, 2002 1:07 PM
> To: Henry Sinnreich; [email-masked]; Robert Sparks;
> [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]