Re: [rtcweb] Use of offer / answer semantics

[Dzonatas Sol <[e-mail]>]

The main thing that concerns me with SIP is the stateful-ness, yet maybe 
that is not of any concern for mobile-phones. I look at this from 
evolution of RFC 2516 such that support of SIP in rtcweb allows return 
to stateless modes (in interop) where before we could assume stateless 
before specific sections on-the-wire and stateful after known points. 
Now people want that transition in the application layer and assume 
HTTPS is ok for stateful-ness. I can see why the multiplex route is 
desired, instead.

Maybe NAT64 can be in-scope if it includes some more stateful PPPoE 
alternative. That would lead to "insider" and "outsider" modes for wi-fi 
(and on-the-wire for plug-ins), so I doubt current interest exist in 
this kind of change for standard.

If, however, SIP and rtcweb work together on S/MIME and SSRC for 
stateful-ness than this could get easier (at least in half-duplex).

On 09/08/2011 09:05 AM, Roman Shpount wrote:
> If the goal is to create something that will interop with an existing 
> SIP infrastructure using a signalling proxy only, we would need is to 
> fully support RFC 3264. I think what we will need is an ability to 
> generate an initial offer (as SDP), process the provisional SDP 
> response, process final SDP response, process an offer and generate 
> the response, and generate a new offer for the existing call (similar 
> to the response to the SIP INVITE with no body) in accordance with 
> rules in RFC 3264. We will need to decide which SDP related RFC would 
> need to be supported, but I think RFC 4566, RFC 3551, RFC 5245, and 
> RFC 3605 are the minimum.
> _____________
> Roman Shpount
>
>
> On Thu, Sep 8, 2011 at 11:52 AM, Paul Kyzivat <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On 9/8/11 12:45 AM, Bernard Aboba wrote:
>
>
>         �> > 1) The media negotiations will be done using the same SDP
>         offer/answer semantics that are used in SIP.
>         �> To be precise - you're suggesting that we use RFC 3264
>         offer/answer
>         �> semantics. (That RFC is 25 pages long. RFC 3261, the core
>         SIP document,
>         �> is 269 pages, and is NOT a normative reference from 3264. I
>         am anxious
>         �> to avoid having a normative dependency on 3261.)
>         �>
>         �> I agree with this.
>
>         [BA] I do *not* agree that RTCWEB should have to support every
>         aspect of
>         SDP offer/answer. Basic offer/answer, sure. All potential
>         corner cases?
>         Not necessarily.
>
>
>     I'm not sure where you are going here?
>     Are you suggesting that all the mandatory to implement O/A
>     semantics of 3264 might not be supported? Or are you saying that
>     O/A support may not work for all defined SDP extensions?
>
>     I think that all mandatory O/A should be supported. If you have
>     something specific in mind that is problematic, then maybe we
>     should investigate why you think it needs to be excluded. My guess
>     is that maybe it is something broken in the spec that ought to be
>     fixed there.
>
>
>         �> > 2) It will be possible to gateway between legacy SIP
>         devices that
>         support ICE and appropriate RTP / SDP mechanisms and codecs
>         without
>         using a media gateway. A signaling gateway to convert between the
>         signaling on the web side to the SIP signaling may be needed.
>
>         �> I agree with this - I think the "may be needed" will turn
>         out to be
>         �> "will be needed", but some portion of that gateway can be
>         implemented by
>         �> Javascript running in the browser, if desirable.
>
>         [BA] This seems like a good principle, but I'm not clear that
>         it will
>         work with all use cases. For example, what happens in the E911
>         use cases
>         when an RTCWEB implementation attempts to make a call to a PSAP
>         implementing NENA i3 Stage 3? If you don't have a media
>         gateway, then
>         the browser will need to implement one of the mandated codecs
>         on the
>         PSAP side. So in those use cases, eliminating the media
>         gateway implies
>         making G.711 and H.264 mandatory-to-implement.
>
>
>     AFAIK, not every rtcweb application will be obligated to support E911.
>     (In particular, any application that doesn't identify callees by
>     phone number is a good candidate to be exempt from E911.
>
>     Certainly a server without a media gateway will be limited in what
>     it can call based on codec compatibility. That may or may not be a
>     limitation, depending on the application. Those that find it an
>     unacceptable limitation will probably find a way to incorporate a
>     transcoder when needed.
>
>     � � � �Thanks,
>     � � � �Paul
>
>     _______________________________________________
>     rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>    


-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant