[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