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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 9 Dec 2002 17:33:41 -0000

Christian and Al are leading in the right direction.

We still seem to be defining the need for early media based on what the PSTN does.

Yes, we do need to solve the PSTN case, but I would agree with Christian that in the pure SIP case we do not need it.

As far as I can see, people are trying to solve the case of sending a message saying "I am in the garage, please call later" before answer. In the PSTN case, this is not possible except in the case of network provided services like 0800 and so on. Moreover, the PSTN (ISDN) only goes to the ringing state (roughly equivalent of a 180 being sent) to provide such a service, because that state has a 3 minute timer, whereas the call proceeding state (roughly equivalent to a 183 being sent) has a much shorter timer which may time out before the answer has been completed. Remember also that the ISDN inherits many of these fudges because PSTN signalling went through a period of being significantly in-band, not because it needed it for its own purposes.

For the case of the user provided message, I would content the call is answered to send this. Why is this any different from going into voicemail. OK, in voicemail the calling user may be able to load a message, after receiving the announcement. But the important fact is that the called user is able to send a message that is specific to that called user, rather than some intermediate server stepping in on behalf of that called user.

So in summary, solve early media for interworking with systems that do not provide an answer signal prior to generating such information, but for all other cases, rely on the answer signal, and make SIP users generate such an answer signal before sending data.

Then deal with the usage specific charging issues based on this agreement - its perfectly possible. For those systems that charge based on bits transferred as far as I can see it makes no difference.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> -----Original Message-----
> From: Al Varney [mailto:[email-masked]]
> Sent: 07 December 2002 15:23
> To: [email-masked]
> Subject: RE: [Sipping] Re: Meaning of status codes
> 
> 
> At 02:36 PM 12/6/02 -0700, Hearty, John wrote:
> >Like it or not, SIP-PSTN interworking is happening, and 
> could possibly be 
> >a dominant early use of SIP.  Users will expect to hear 
> media (tones, 
> >announcements) provided by the PSTN prior to answer, and 
> will expect no 
> >clipping of the PSTN callee's "Hello."  It is safe to say 
> these are hard 
> >requirements that need to be met, they cannot be ignored in 
> favor of a 
> >beautiful, simple solution.
> >
> >I watch this thread with great interest, anticipating a 
> solution meeting 
> >the above requirements.  I would agree with those who 
> discourage the use 
> >of early media for native IP applications, where the desired user 
> >experience could be attained through other methods, thereby 
> (hopefully) 
> >keeping session initiation complexity to a minimum.
> 
>     The solution is obvious:  Never use 180 on SIP-to-PSTN 
> calls through a 
> gateway.  Always use 183 with "recv only" or "sendrecv".  
> In-band ringback 
> or other tones are ALWAYS furnished by the PSTN.  Clipping in 
> the backward 
> direction disappears.  Clipping in the forward direction 
> will, as in ISUP 
> today, require the "answer" signalling to get back through 
> any gateway/UA 
> that isn't set to "sendrecv".
> 
>     This solution was an option in the SIP-ISUP draft-04, 
> prior to the 
> hurried changes during Last Call (in draft-05) that were 
> anti-early-media.  Jon's suggestion at the time was that 
> early media needed 
> to be addressed for all of SIP, not just for SIP-PSTN 
> interworking, so we 
> should allow the draft to go forward and propose changes after a more 
> robust generic SIP mechanism/framework was agreed (after 
> November IETF).
> 
>     Now I'm hearing that whatever this "more robust" early 
> media framework, 
> it needs to be backward-compatible with SIP-ISUP-05, which 
> means it has to 
> follow a rushed and (IMO) incomplete mechanism.
> 
>     As I recall, SIP-ISUP-draft-05 was cast in stone in 
> August -- remind me 
> again what the rush was to get it in the Editor's queue, rather than 
> allowing the discussion to complete as part of Last Call?  
> And why did we 
> have to hold further discussion until after November IETF?
> 
>     Alternatively, follow Christian Huitema's more "SIP-pure" 
> suggestion 
> that a PSTN gateway send 200 OK for "early media" cases (so 
> it's no longer 
> "early").  After all, the UAS to PSTN-gateway SESSION is 
> established -- 
> some other message can send "answer/charging begins", which 
> probably only 
> makes sense for PTST interworking anyway.  Those using SIP over 
> bandwidth-scarce interfaces (3GPP) would then be assured that 
> receipt of 
> 180 really meant that there is no media to be received.
> 
> -----
>     While I'm on the subject, (from the "Early media draft" thread):
> At 03:14 PM 11/26/02 -0800, Francois Audet wrote:
> 
> >2. But in certain cases, the gateway DOES know that the far end
> >is being alerted AND that in-band media is available. In that case
> >it can send both the sendrecv and the 180. This will cause no harm.
> >The phone can just do whatever it is supposed to do when receiving
> >a 180 (i.e., text indication, or providing local ringback overriding
> >any in-band voice).
> 
>     This isn't the case (IMO) for SIP-ISUP gateways, since I 
> don't believe 
> ISUP provides a reliable indication of "being alerted" (as 
> opposed to "line 
> is free", which isn't the same thing).  And that's the reason I was 
> concerned about the changes from Draft-04 to Draft-05.  Jon suggested 
> waiting until "generic SIP early media" was ironed out before 
> re-opening 
> any update to SIP-ISUP.  I'm still waiting.
> 
> >3. And finally there is the last case (the one that doesn't 
> work if you
> >turn off the normal treatment of 180, as per the example in 
> the draft).
> >This case is when there is a 180 and a sendrecv but NO 
> inband ringing. This
> >will happen often when a PSTN gateway makes a call on an 
> ISDN interface and
> >stays ISDN end-to-end (because in that case, many 
> implementations will
> >behave like "normal" SIP and will NOT provide in-band ringing).
> 
>     I'm presuming this is a SIP-ISDN gateway, not a SIP-ISUP 
> gateway.  I 
> don't know of any ISUP that doesn't provide in-band ringing on voice 
> calls.  Folks have suggested it exists, and some books on ISUP have 
> described it.  But I'd really like to try calling it from an 
> ISDN phone in 
> the USA.  There, audible ringing tone (ringback) is always 
> presumed to be 
> generated at the terminating exchange or a PBX connected to 
> that exchange 
> (see ANSI T1.609).
> 
> -----
>    Forking with early media is another issue -- but it seems 
> to avoid the 
> question of what to do with multiple 200 ACKs from forked 
> INVITEs.  Can one 
> really think there will only be one 200 ACK, and that the 
> other possible 
> answering parties won't be upset if their call is ignored?  
> (I can get that 
> treatment today from telemarketers.)
> 
>     Also, what happens if you receive several 180 codes with "sounds" 
> embedded inside -- which do you pick to play?
> 
>     Christian H. is correct:
>  > 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'd note that, from my non-SIP-expert viewpoint, the 
> "early media" 
> problem exists because SIP does not appear to support the 
> serial "hand-off" 
> of a session from UAC to UAC to UAS (that's the insertion of short 
> announcements, call progress tones, etc. as the session is 
> established).  If it did so, there wouldn't be a need for 
> "early media", 
> which allows 200 ACK to mean "I'm done handing off the 
> session".  Then all 
> media could occur after 200 OK and explicit messages could 
> indicate the 
> movement of the session end-point from one UAC/UAS to another (if the 
> originator even cares to know about the movement).  "Answer" would be 
> discarded as an old PSTN concept.  Sorry, got carried away....
> 
>     OK -- I'll shut up for awhile (again).
> 
> Al Varne
> 
> _______________________________________________
> 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: Christer Holmberg <[email-masked]>
Date: Tue, 10 Dec 2002 14:02:02 +0200

Hi,

We seem to spend a lot of time arguing about it early media shall be used between SIP nodes, or only in interworking cases.

Let's assume for a while that early media would be used ONLY in interworking cases. Then we need to answer the following questions:

1. In a SIP-to-PSTN call, how does the gateway indicate to the remote SIP phone that early media may arrive?

2. In a PSTN-to-SIP call, how does the remote SIP phone indicate to the gateway if there may be early media (ie how does the gateway know if it should generate local ringback towards the PSTN network or not)?

Now, one may argue that the second question is not valid, since we assumed SIP nodes won't generate early media.

BUT, what if the SIP node is another gateway, ie we have a trunking case? Will we prevent early media in trunking cases?

I think these are REQUIRMENT questions we have to solve first, toghether with the backward compability issues mentioned in other mails - otherwise we will go on with this discussion forever...

Regards,

Christer Holmberg
Ericsson Finland