RE: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer

["Francois Audet" <audet@xxxxxxxxxx>]

Actually let's NOT assume HERFP is solved...

 

> -----Original Message-----
> From: Dan Wing [mailto:dwing@xxxxxxxxx] 
> Sent: Friday, November 03, 2006 1:40 PM
> To: 'Desineni, Harikishan'
> Cc: ietf-rtpsec@xxxxxxx; mmusic@xxxxxxxx; carrara@xxxxxx
> Subject: RE: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer
> 
> > > > Sec 8.4.2 of RFC3388 suggests that the offer re-try without 
> > > > "group".  That may not look good, but is not too bad either.
> > > 
> > > That probably works alright with RTSP, but doesn't work with SIP 
> > > forking due to HERFP (Heterogeneous Error Response 
> Forking Problem).
> > 
> > HERFP is a problem with SIP that anyways needs to be solved at some 
> > other place.
> 
> I admit to not following it closely, but it seems HERFP 
> hasn't yet been solved in SIP or SIPPING.
> 
> However, let's assume, for a minute, that HERFP is solved.  
> If my endpoint supports supports RTP, SRTP, feedback, and 
> running RTP over DCCP or over UDP, I would need to send an 
> SDP that contains 8 m-lines (RTP/AVP, RTP/AVPF, RTP/SAVP, 
> RTP/SAVPF, DCCP/RTP/AVP, DCCP/RTP/SAVP, DCCP/RTP/AVPF, 
> DCCP/RTP/SAVPF), and each m-line would have duplicated ICE 
> attributes for all of the UDP transports and all of the 
> m-lines would have duplicated codec attributes.  This makes 
> for a _very_ long SDP, and requires anyone receiving it to 
> understand port overloading.
> 
> -d
> 
> _______________________________________________
> mmusic mailing list
> mmusic@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/mmusic
>