Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

|Not really - there will be signaling, because there has to 
|be SDP answers even just to get ICE to work before the media 
|starts flowing in many NAT cases.  And even in practice in 
|SIP there're usually SDP answers in 18x to open "gates", and 
|to get upstream DTMF.  So if the concern is just that there's
|no signaling to tell the browser there are multiple RTP streams
|coming, I think that can be allayed.

I think it is further allayed with ICE because ICE requires that early
media be not sent until the ICE connectivity check is done and a valid
candidate pair is selected -- it requires implementations to delay
alerting the called party until this point (in the case of a PSTN
gateway, this would mean that the setup message into the PSTN is delayed
until this point). So, the RTCWeb app would have to just create a single
PeerConnection object for receiving/transmitting a media stream once
this procedure is completed.
 
Of course there is complexity in the SIP/PSTN interworking gateway, but
it doesn't look the RTCWeb app would have worry about it.

Muthu

|-----Original Message-----
|From: [e-mail] [mailto:[e-mail]] On
Behalf Of Hadriel Kaplan
|Sent: Wednesday, September 21, 2011 4:06 AM
|To: Cullen Jennings (fluffy)
|Cc: [e-mail]
|Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP
negotiation mechanism
|
|
|On Sep 20, 2011, at 4:07 PM, Cullen Jennings wrote:
|
|> That said, I think that doing both forking and early media is hard.
Lets assume we are using a
|signaling gateway that is not a media gateway to translate between a
SIP call on one side and whatever
|is happening over on the browser side. The basic issue is the browser
initiating the communications
|needs to be able to start receiving multiple RTP streams before it even
has signaling information to
|tell it how many it might receive.
|
|Not really - there will be signaling, because there has to be SDP
answers even just to get ICE to work
|before the media starts flowing in many NAT cases.  And even in
practice in SIP there're usually SDP
|answers in 18x to open "gates", and to get upstream DTMF.  So if the
concern is just that there's no
|signaling to tell the browser there are multiple RTP streams coming, I
think that can be allayed.
|
|The really hard part is knowing which stream to use/render/send-to,
imho.  And putting that decision
|in the gateway isn't good - the best decider of that is probably the JS
in the browser.
|
|
|> To simplify this problem, Cary and my draft proposes not allowing
forking on the SIP side of the
|signaling gateway but still allowing early media. If you wanted to do
do forking in this case, one
|would need a SBC that processed media and turned the forked medial legs
into one media leg.
|
|Obviously you can request that a request not be forked, using
caller-prefs, but you can't "not allow"
|forking on the SIP side.  That would make it not SIP.  I know forking
is hard, but that's life.  It's
|not appropriate for this WG to make fundamental changes/limitations to
the SIP protocol, just because
|some of it's "hard" for a browser.
|
|-hadriel
|
|_______________________________________________
|rtcweb mailing list
|[e-mail]
|https://www.ietf.org/mailman/listinfo/rtcweb