Subject: [Sipping] New version of netann

From: "Eric Burger" <[email-masked]>
Date: Tue, 4 Mar 2003 09:04:57 -0500

Before it shows up in the archives, here is a copy:
http://flyingfox.snowshore.com/i-d/sip/draft-burger-sipping-netann-05.txt
http://flyingfox.snowshore.com/i-d/sip/draft-burger-sipping-netann-05.html

The -05 version of netann incorporates the following changes:

409 Result Code
===============
Due to popular demand, rather than using 487, we use 409.  See the text for more information.  Note that the case brought up on the list of a UAC that ignores 487 response codes is clearly a case of a broken UAC.  That UAC must terminate the dialog upon the receipt of ANY 4xx code.

100rel
======
Everyone we actually interoperate with uses 100rel.  It's now in the document as a SHOULD.

Conference Indicator
====================
The conference indicator is now simply "conf".  The conference identifier is now a parameter.  Some (non-conforming) proxies may not do the right thing.  Please read the "special note".

Other Issues Brought Up on the List:

Session Termination Timing
==========================
Bill Marshall brought up the possibility that a BYE from the media server might not arrive at the UAC at the same time as the end of the media.  In our experience, if the media server issues the BYE after finishing playing out the media, the BYE arrives at the UAC after the media finishes playing.

In the worst case, let's say the media server is sending 200ms buffers.  If the UAC flushes playing the buffer upon receipt of the BYE (which is very unlikely), the final 200ms will be clipped.  That probably will not be noticed.

One might have a media server that sends packets faster than real time.  For example, consider a six second prompt.  For 200ms packets, this would require 30 packets.  A media server that sends packets faster than real time would send packets faster than one every 200ms.  This could break the UAC.  That said, the media server, in this case, would be a VERY BAD INTERNET CITIZEN.  It would be breaking most of the RTP statistical multiplexing assumptions, and would most likely overflow the UAC's buffer.  Thus this is a corner case that netann does not have to deal with.

Dave Oran noted that most announcements get repeated, so clipping 200ms of a 12s+ prompt probably won't be noticed.

Moreover, just about all of the discussions about the different paths the RTP and SIP signaling take are about how much longer the SIP signaling takes versus the RTP.  That is, the UAC will have received and played out the buffer long before it receives the BYE.

IVR Use
=======
Luca Prati asked about using netann for IVR-style interactions, such as reading out advice of charging (a complex prompt) and mid-call announcements.

AOC can be done with sequences.  The netann document specifies an interface to sequences, but it does not describe how to specify prompt sequences.  A follow-on document will describe how this is done.

Mid-call announcements can be done by reinviting the call to the announcement service.  However, one would expect a more rich interactions, such as playing the announcement over the called party.  Netann is specifically NOT suited to this use and the document states that.  See mscml for one way of doing this.

"Early" URI Parameter
=====================
Christer Holmberg pointed out his preference for coming up with a generic "this session is early" mechanism.  At this time, I'm not sure that this is something that occurs in other situations.  Given that, we've left in the early parameter.

I would agree that the UAC might not support early media.  However, the onus would be on the proxy, not the media server, to enforce 100rel.  If the UAC doesn't support 100rel, then the proxy should request it.
_______________________________________________
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: Wed, 05 Mar 2003 11:25:05 +0200

Hi Eric,

I haven't had time to look at the new version of the draft yet, but I'd like to comment my comments :)

> "Early" URI Parameter

[CHH] I think that early media DO occur in other situations (at least in PSTN interworking). At least I assume so, since there has been much discussion about it lately...

> I would agree that the UAC might not support early media.  However, the onus would be on the proxy, not the media server, to enforce 100rel.  If the UAC doesn't support 100rel, then the proxy shoul…

[CHH] Do you mean that the proxy is going to insert Require: 100rel in the request, then handle the sending of PRACK, and make sure that retransmissions of 18x messages received by that proxy aren't forwarded back to the UAC, etc etc?

Or, do you mean that the proxy will send a 421 Extension Required response back to the UAC?

Regards,

Christer Holmberg
Ericsson Finland