Subject: RE: [Sipping] New version of netann

From: "Eric Burger" <[email-masked]>
Date: Wed, 5 Mar 2003 16:05:58 -0500

As it stands now, you would need multiple INVITEs.

Otherwise, how would one correlate the play's with m-lines?

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, March 05, 2003 2:19 PM
> To: Eric Burger
> Cc: Sipping (E-mail)
> Subject: Re: [Sipping] New version of netann
> 
> 
> 
> Hi Eric,
> 
> A question on the draft, related to the functionality.
> 
> Assuming there is a media stream service which consists of 
> both audio and video, identified with different promt-urls, 
> do I have to send separate INVITEs for those (in RTSP
> separate SETUPs and PLAY are sent)? Or, is it possible to 
> include multiple play parameters in a single INVITE Request-URI?
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
_______________________________________________
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 23:24:23 +0200

Hi Eric,

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

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 :)

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

Regards,

Christer Holmberg
Ericsson Finland