Subject: RE: [Sipping] New version of netann

From: "Eric Burger" <[email-masked]>
Date: Fri, 14 Mar 2003 10:08:47 -0500

Inline.

> Original Message From: Christer Holmberg [mailto:[email-masked]]
[snip]
> > >Well, you could define the play's as SDP attributes. 
> Something like:
> > >
> > >m=audio...
> > >a=play:"http://audio.example.net/allcircuitsbusy.g711";
> > >m=video...
> > >a=play:"http://video.example.net/allcircuitsbusy.mpeg4";
> > >
> > >I don't know if this would work (I haven't had time to 
> think so much
> > >about it) the way you've planned, though.
> >
> > It might work, except error handling would be horrific.  A 
> fetch error would have to be reported as an SDP error, for example.
> 
> Well, you could return 200 OK with an SDP, with the port set 
> to zero for the specific stream. That's how we do it in 
> "normal" SIP calls, so... Or, you could send 415 Unsupported 
> Media Type.

The problem is, is the 415 because the fetch failed or because I don't support G.mumble?  Yes, one might be able to work it out from the parameters given in the 415, but that sounds like a lot of machinery.

> 
> > >But, if we need multiple INVITEs, would it be possible to associate
> > >them? We would have to use different call identifiers etc 
> (I hope you
> > >wouldn't want to use something similar to overlapping for this :)
> >
> > Is this a real issue?
> 
> What? Being able to associate the INVITEs, or having to send 
> multiple INVITEs? At least regarding the issue of multiple 
> INVITEs, I think multimedia streams (including eg audio AND 
> video) IS a real issue...

The unfortunate thing is, I think I agree with you.  Does anyone have a thought on how to do this?  My initial thinking is I don't want the URI to play in the SDP, because that is a signaling thing, not a media thing.  However, I don't see a nice way of correlating what to play over which stream, without something like a stream ID in the SDP that gets referenced in SIP.

> > >Another question I have, is related to the media mode attributes.
> > >
> > >Assume I send a re-INVITE during the session, to put the media
> > >"on-hold". Now, does this mean that the stream will be
> > >"paused", or does it mean that I just won't receive it? 
> Personally I would say that the
> > >second alternative is more according to the semantics, but in a
> > >streaming environment some may disagree...
> >
> > I hadn't thought about it before, as we've never seen it 
> happen.  I suppose it could happen, however.  I'm hesitant to 
> standardize the behavior.  If we say "hold=pause session", 
> then we're opening ourselves up to a major denial-of-service attack.
> 
> If it's supposed to work as it normally does, there is no 
> need to standardize anything. But, in that case I guess it 
> will not be able, with your current draft, to put media on 
> hold. I guess it's not needed for announcements etc, but my 
> understanding
> is that the scope of your draft includes also real, 
> established, streaming sessions.

I think the thing to do is say that putting announcement media on hold may have unpredictable results.  The PSTN emulation behaviour would be to virtually continue play out, and then resume from the time index of the re-re-INVITE bringing us off hold.  The *easy* thing to do is suspend playing.

The scope of the draft w.r.t. annc, ivr, and dialog is announcements or interactive sessions.  The only service where "established" sessions might be an issue is conf.  However, for conf the semantics are clear and straightforward.

Thinking of my comment above concerning putting an annc on hold, it doesn't really follow for ivr and dialog services.  Vote time: should we suspend ivr and dialog sessions on receipt of hold, or should we time-forward them?
_______________________________________________
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: Tim Melanchuk <[email-masked]>
Date: Fri, 14 Mar 2003 11:08:36 -0800

at the end...

[snip]
> Thinking of my comment above concerning putting an annc on hold, it doesn't really follow for ivr and dialog services.  Vote time: should we suspend ivr and dialog sessions on receipt of hold, or s…

i believe that all should time-forward. services such as ivr
and dialog involve bi-directional interactions. each direction
can be independently put on hold. requesting that one direction
be put on hold, should not influence the stream in the opposite
direction. for example, if a user requests that the stream from
a media server be put on hold, it does not mean that they will
not send to the media server, only that the media server should
not send.

since transitions from a=sendrecv to a=sendonly or a=recevonly
should not pause an ivr or dialog service, i don't think that
a=inactive should be special cased to pause the service.

then, since hold would not affect the conf, ivr, or dialog
services, it would not be consistent to have it affect the
ann service.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Mar 2003 23:52:27 +0200

Hi Eric,

> >>>think so much about it) the way you've planned, though.
> >>

[CHH] Well, 200 OK (or a reliable 18x provisional response) with the port set to zero for streams not accepted, is another option. Then, the client can make a decission if it wants to continue with the announcement or not.

> >>>(I hope you wouldn't want to use something similar to overlapping for this :)
> >>
> >>Is this a real issue?
> >
> The unfortunate thing is, I think I agree with you.  Does anyone have a thought on how to do this?  My initial thinking is I don't want the URI to play in the SDP, because that is a signaling thing, not a media thing.

[CHH] These specific URIs defines "media objects", and not a location (like the Request-URI), so one could argue they are related to the media.

Regards,

Christer Holmberg
Ericsson Finland