Subject: RE: [Sipping] Re: Meaning of status codes

From: "Francois Audet" <[email-masked]>
Date: Fri, 6 Dec 2002 11:44:27 -0800

In the case of forking, I believe Christian is absolutely right. No matter
how much we try,
if we do early media we have a 1-chance-in-N of the early media to be
appropriate.
Consequently, only sending the media after the 200 (called side) works.
Sending early media will not be useful. 

We should be very careful then with early in-band ringback/announcement and
clipping avoidance.

Early-media (for clipping avoidance) does not seem to be an issue as only
one endpoint
will eventually answer.

Early-media for early-ringback/announcement howere is more troublesome. The
rationale for
supporting this has always been mostly PSTN interworking. It seems that the
idea of
answering the call artificially (200) to provide inband ringing was turned
down for 
billing/accounting purposes. Assuming that we do not override this decision,
it seems to 
indicate that we do need to support early-ringback/announcement in the case
of PSTN interworking 
(and yes it will have some interesting effects on forking: calls that sounds
busy and then is 
answered, message saying "number disconnected" and then an answer, etc). I'm
not sure
that there is a solution to these side-effects.

We do have a choice however on what we do when there is NO PSTN
interworking. It looks like
Christian is arguing for NOT allowing early-ringback/announcement. That
would imply that
in order to satisfy Gonzallo's "I'm in currently working in the garage"
alerting announcement,
you'd have to answer the call artificially (like an answering machine). 

This seems to be a fundamental question to answer.

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]] 
> Sent: Thursday, December 05, 2002 6:00 PM
> To: Peterson, Jon; William Marshall
> Cc: [email-masked]
> Subject: RE: [Sipping] Re: Meaning of status codes
> 
> 
> The only solution that actually works is to only send media 
> after receiving the 200 (sender) and the ACK (receiver). All 
> the other solutions are based on the desire to overload the 
> SIP session establishment message with some other function, 
> e.g. map to ISUP or map to accounting events. I believe such 
> mapping is fundamentally impossible.

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 06 Dec 2002 15:14:40 -0600

There was a time when most of data network design by some was focused
(wrongly) on interfacing with the mainframe front-end processor to SNA
networks. Many people on the list may not remember it. 

Focusing SIP design on 100% equivalence with PSTN will be similar
forgotten. 

> mapping is fundamentally impossible. 

I also think Christian is right and let's put this to rest, unless there
are clarifications to existing SIP documents.

SIP is no longer an academic exercise, but has a solid product base that
cannot be upset for trivial reasons IMHO (or for closed network designs)
- keep here only what is backward compatible and is applicable to the
public Internet.

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Francois Audet
Sent: Friday, December 06, 2002 1:44 PM
To: 'Christian Huitema'; 'Peterson, Jon'; 'William Marshall'
Cc: [email-masked]'
Subject: RE: [Sipping] Re: Meaning of status codes

In the case of forking, I believe Christian is absolutely right. No
matter how much we try, 
if we do early media we have a 1-chance-in-N of the early media to be
appropriate. 
Consequently, only sending the media after the 200 (called side) works. 
Sending early media will not be useful. 
We should be very careful then with early in-band ringback/announcement
and clipping avoidance. 
Early-media (for clipping avoidance) does not seem to be an issue as
only one endpoint 
will eventually answer. 
Early-media for early-ringback/announcement howere is more troublesome.
The rationale for 
supporting this has always been mostly PSTN interworking. It seems that
the idea of 
answering the call artificially (200) to provide inband ringing was
turned down for 
billing/accounting purposes. Assuming that we do not override this
decision, it seems to 
indicate that we do need to support early-ringback/announcement in the
case of PSTN interworking 
(and yes it will have some interesting effects on forking: calls that
sounds busy and then is 
answered, message saying "number disconnected" and then an answer, etc).
I'm not sure 
that there is a solution to these side-effects. 
We do have a choice however on what we do when there is NO PSTN
interworking. It looks like 
Christian is arguing for NOT allowing early-ringback/announcement. That
would imply that 
in order to satisfy Gonzallo's "I'm in currently working in the garage"
alerting announcement, 
you'd have to answer the call artificially (like an answering machine). 
This seems to be a fundamental question to answer. 

> mapping is fundamentally impossible. 

_______________________________________________
Sipping mailing list  https://www1.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