Subject: RE: [Sipping] New version of netann

From: "Eric Burger" <[email-masked]>
Date: Thu, 6 Mar 2003 15:15:09 -0500

Inline

> Original Message From: Christer Holmberg [mailto:[email-masked]]
> > As it stands now, you would need multiple INVITEs.
> >
> > Otherwise, how would one correlate the play's with m-lines?
> 
> 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.

> 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?

> 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.
_______________________________________________
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: Fri, 07 Mar 2003 08:04:49 +0200

Hi Eric,

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

> >wouldn't want to use something similar to overlapping for this :)

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

> >"paused", or does it mean that I just won't receive it? Personally I would say that the

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.

Regards,

Christer Holmberg
Ericsson Finland