[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] SDP CapNeg and forking
Christer,
> -----Original Message-----
> From: mmusic-bounces at ietf.org
> [mailto:mmusic-bounces at ietf.org] On Behalf Of Christer Holmberg
> Sent: 10 November 2008 04:10
> To: mmusic at ietf.org
> Subject: [MMUSIC] SDP CapNeg and forking
>
>
> Hi,
>
> Assume a UA sends a SIP INVITE, with an SDP offer that
> contains a number of different alternatives/configuratoins,
> using CapNeg mechanism(s).
>
> Now, the INVITE is forked to a number of terminating UAs.
>
> The terminating UEs send back 18x responses with SDP answers,
> where there different terminating UAs chooses DIFFERENT
> alternatives/configurations.
>
> Now, what does the originating UA do?
>
> Does the originatin UA have to simulatnously reserve
> resources for, and be able to support, ALL of the chosen
> alternatives/configurations, until it knows from which of the
> terminating UAs it will receive 200 (at that point it can
> release all resources associted with the other terminating UAs)?
[JRE] I don't see any alternative, do you?
John
>
> And, of course intermediates will have the same problem: even
> if they support CapNeg, they may end up having to support
> multiple alternatives/configurations simultanously.
>
> Of course, and could say that we can have the same problem
> even without CapNeg, if the terminating UAs indicate
> different codecs etc in the SDP answers. But, with CapNeg one
> can give much "broader" alternatives, so it may be much more
> difficult to deal with SDP answers indicating different alternatives.
>
> So, do we need to say something about it?
>
> I know MMUSIC doesn't deal with SIP, but I think we all agree
> that SIP will be the main (only?) "customer" of CapNeg.
>
> Regards,
>
> Christer
>
>
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic