Subject: [MMUSIC] SDPCapNeg : Modified m= line in 1st answer

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 10 Mar 2008 23:22:04 +0100

Hi

I have one question regarding the modified "m=" line in the 1st answer when using SDPCapNeg.
An example is for instance that the 1st offer might specify
m=audio 54568 RTP/AVP 0 18 
while the 1st answer  specifies
m=audio 54555 RTP/SAVP 0 18 

The risk with this may be that an intermediate may reject the 1st answer for policy reasons with unknown results.

Why not then leave the m= line in the 1st answer as is i.e
m=audio 54555 RTP/AVP 0 18 
and let the acfg line determine the transport ?. 

A 2nd offer/answer would then (in the above example) look something like
2nd offer : m=audio 54568 RTP/SAVP 0 18 
2nd answer: m=audio 54555 RTP/SAVP 0 18 

This of course means that the 2nd offer/answer must be mandated but I beleive that this approach is more clean-cut and robust.

Similar issues, if not resolved, may also pop up in the future for instance if the "c=" -line is modified like is proposed in 
http://tools.ietf.org/wg/mmusic/draft-garcia-mmusic-sdp-cs-00.txt
So I believe that this question is justified in this forum.

/Ingemar
*******************************************
Ingemar Johansson
Senior Research Engineer, IETF "nethead"
EAB/TVP - Multimedia Technologies
  Ericsson Research Ericsson AB
  Box 920 S-971 28 Luleå, Sweden
Tel: +46 (0)8 4043042
ECN: 850-43042
ECC: 850-43074
Mobile: +46 (0)730 783289
*******************************************

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Randell Jesup <[email-masked]>
Date: Thu, 13 Mar 2008 12:09:03 -0400

>for policy reasons with unknown results. 

It is possible an SBC could do something like this.  Hopefully not, but
possible.

>This of course means that the 2nd offer/answer must be mandated but I
>beleive that this approach is more clean-cut and robust. 

A second-round re-INVITE was carefully avoided in how offer-answer is
designed, and also part of what capability negotiation was meant to
avoid.  If you have a second round, then you could first say "I can do
this", then say "Ok, now that I know what you do, here's my choice".
A two-round negotiation can be done, but it does add an extra RTT delay
(plus some), and some complexity.

That said, we could go this way - but I want us to have a clear idea of
what it is we're doing, and why, and how we got here.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 13 Mar 2008 19:41:20 +0100

Hi

Just some lose speculation around this...

One possible way to solve this is that some attribute is specified on
session level that determines if the offerer likes the 1st answer in one
way or the other. Lets say that the atribute has the name
"mandate-2nd-offer-answer"

If the 1st offer has the attribute 

a=mandate-2nd-offer-answer 

on session level, the 1st answer MUST not do the additional
modifications to  the m= line in the way that is described in the
SDPCapNeg draft, however to make a valid session setup possible a second
offer/answer is a MUST.

If the given attribute does not exist on session level, then the same
rules as specified in the SDPCapNeg draft applies.

This way both alterantives are possible. I may have missed issue here,
so please let me know if it is doable or not.

/Ingemar 

> -----Original Message-----
> From: Randell Jesup [mailto:[email-masked]] 
> Sent: den 13 mars 2008 12:09
> To: Ingemar Johansson S
> Cc: [email-masked]
> Subject: Re: [MMUSIC] SDPCapNeg : Modified m= line in 1st answer
> 
> >An example is for instance that the 1st offer might specify m=audio 
> >54568 RTP/AVP 0 18 while the 1st answer  specifies m=audio 54555 
> >RTP/SAVP 0 18
> >
> >The risk with this may be that an intermediate may reject the 1st 
> >answer for policy reasons with unknown results.
> 
> It is possible an SBC could do something like this.  
> Hopefully not, but possible.
> 
> >Why not then leave the m= line in the 1st answer as is i.e m=audio 
> >54555 RTP/AVP 0 18 and let the acfg line determine the transport ?.
> >
> >A 2nd offer/answer would then (in the above example) look something 
> >like 2nd offer : m=audio 54568 RTP/SAVP 0 18 2nd answer: 
> m=audio 54555 
> >RTP/SAVP 0 18
> >
> A second-round re-INVITE was carefully avoided in how 
> offer-answer is designed, and also part of what capability 
> negotiation was meant to avoid.  If you have a second round, 
> then you could first say "I can do this", then say "Ok, now 
> that I know what you do, here's my choice".
> A two-round negotiation can be done, but it does add an extra 
> RTT delay (plus some), and some complexity.
> 
> That said, we could go this way - but I want us to have a 
> clear idea of what it is we're doing, and why, and how we got here.
> 
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), 
> ex-Amiga OS team [email-masked] "The fetters imposed on 
> liberty at home have ever been forged out of the weapons