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

From: "Hearty, John" <[email-masked]>
Date: Fri, 6 Dec 2002 15:25:56 -0700

inline.

> -----Original Message-----
> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 2:15 PM
> To: 'Francois Audet'; 'Christian Huitema'; 'Peterson, Jon'; 'William
> Marshall'
> Cc: [email-masked]
> Subject: RE: [Sipping] Re: Meaning of status codes
> 
> 
> 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. 
> 

I don't think anyone in this thread is looking to make SIP equivalent to the PSTN.  There seems to have been two reasons folks have been pushing for early media support, one is for fancy messages from native IP terminations such as notifying the caller I am in the attic.  The other is to support media provided by the PSTN (tones/announcements) prior to answer.  The former may be able to be accomplished in very different ways.  It is not yet clear what the best way is to handle the latter, but it is an important case that needs to be handled.

> > 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. 
> 
> I also think Christian is right and let's put this to rest, 
> unless there
> are clarifications to existing SIP documents.
> 

In a perfect world, where everyone has a SIP endpoint and PSTN interworking is not needed, then Christian's suggestion above might be reasonable.  PSTN interworking is a reality, and passing the tones/announcements from the PSTN to the caller is needed.  This cannot be done using Christian's suggestion above on its own.

Perhaps there could be some very different method to deliver this media to the caller other than using early media in the session (perhaps some associated session immediately answered), but I don't suspect such a method could be devised which is compatible with existing SIP devices.

183 with SDP already works in many devices to deliver this PSTN media before answer and solve the clipping problem at the same time.  Let's see if that can be enhanced to work out the kinks with multiple early media streams due to forking, and other important problems.

John

> 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. 
> 
> 
> > -----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. 
> 
> _______________________________________________
> 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
> 
_______________________________________________
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

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 6 Dec 2002 15:20:58 -0800

On Friday, December 6, 2002, at 02:25 PM, Hearty, John wrote:

> I don't think anyone in this thread is looking to make SIP equivalent 
> to the PSTN.  There seems to have been two reasons folks have been 
> pushing for early media support, one is for fancy messages from native 
> IP terminations such as notifying the caller I am in the attic.  The 
> other is to support media provided by the PSTN (tones/announcements) 
> prior to answer.  The former may be able to be accomplished in very 
> different ways.  It is not yet clear what the best way is to handle 
> the latter, but it is an important case that needs to be handled.
>
> In a perfect world, where everyone has a SIP endpoint and PSTN 
> interworking is not needed, then Christian's suggestion above might be 
> reasonable.  PSTN interworking is a reality, and passing the 
> tones/announcements from the PSTN to the caller is needed.  This 
> cannot be done using Christian's suggestion above on its own.

No, this is not true.  Christian's comment/suggestion, which others 
including myself made as far back as the first interim meeting (Feb 
2001) was that the start of billing in the PSTN is confounded with the 
start of a session in SIP and that we should fix that by decoupling 
"start of billing" from the 200 OK to an INVITE.  In other words, PSTN 
early media would cause gateways to send a 200 OK instead of a 18x.  
Later if a billable call began you could optionally send another 
request to indicate that billing was starting (perhaps a reINVITE or an 
INFO).  The proposal was abandoned because the consensus of the group 
was that this would cause backwards compatibility problems with 
existing (RFC2543) gateways.

we could still do this, but we would be breaking a lot more stuff.  I 
was for this proposal in 2001, but I think we are too late to make the 
change now.

thanks,
-roahn

> Perhaps there could be some very different method to deliver this 
> media to the caller other than using early media in the session 
> (perhaps some associated session immediately answered), but I don't 
> suspect such a method could be devised which is compatible with 
> existing SIP devices.
>
> 183 with SDP already works in many devices to deliver this PSTN media 
> before answer and solve the clipping problem at the same time.  Let's 
> see if that can be enhanced to work out the kinks with multiple early 
> media streams due to forking, and other important problems.
>
> John
>
>