Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09

Paul,

Thanks for the clarification. Let us wait for the clarification on R-R issue.

Thanks
Partha

> -----Original Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: Wednesday, June 26, 2013 8:44 PM
> To: Parthasarathi R
> Cc: sipcore@ietf.org
> Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-
> 09
> 
> Partha,
> 
> You addressed your reply to me. But I just posed the question, not the
> answer. I'm waiting for those who proposed the language to clarify it.
> 
> The real issue is: how can a websocket server ever decide that it
> *doesn't* need to R-R?
> 
> 	Thanks,
> 	Paul
> 
> On 6/24/13 8:41 PM, Parthasarathi R wrote:
> > Paul,
> >
> > I think that we are talking about two problems here
> >
> > 1) SIP routing issue because of SIP WebSocket Client has only
> WebSocket as a transport (Browser scenario)
> > 	a) Solution: Record-route header has to be added by SIP WebSocket
> Server.
> >
> > 2) How will SIP WebSocket Server know that SIP WebSocket client
> supports only SIP WebSocket as a transport? (Non-browser scenario)
> > 	a) AFAIK, there is no other environment other than browser has
> the limitation of not supporting UDP & TCP. In case any other
> environment exists, Please let me know.
> > 	b) The beauty of RFC 3261 is that there is no need to negotiate
> the set of "SIP" transport protocol as it mandates for UDP, TCP. I
> agree that it is an open item how to represent the list of transport
> supported by a SIP UA in case of supporting WebSocket only transport
> scenario. But I'm not sure whether this WG is interested in solving
> this issue. We need to here from more folks and its relevant usecases.
> >
> > Thanks
> > Partha
> >
> >> -----Original Message-----
> >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
> >> Behalf Of Paul Kyzivat
> >> Sent: Thursday, June 20, 2013 9:28 PM
> >> To: sipcore@ietf.org
> >> Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-
> websocket-
> >> 09
> >>
> >> On 6/19/13 6:05 PM, Iñaki Baz Castillo wrote:
> >>> 2013/6/19 Parthasarathi R <partha@parthasarathi.co.in>:
> >>>>
> >>>> Just adding to Ranjit mentioned. The text similar to the following
> >> has to be added. "Record-route header MUST be added by SIP WebSocket
> >> Server in case WebSocket is the only supported SIP transport between
> >> SIP WebSocket client & server and SIP WebSocket server acts as SIP
> >> proxy"
> >>>
> >>> That is just true in case the client is a web browser (a SIP WS
> >> Client
> >>> but not a SIP WS Server so it can not receive incoming WS
> >>> connections). So the text would be:
> >>>
> >>> "Record-route header MUST be added by SIP WebSocket Server in case
> >>> WebSocket is the only supported SIP transport between client and
> >>> server, the server acts as SIP proxy, and the client is a SIP
> >>> WebSocket Client (but not a SIP WebSocket Server so it can not
> accept
> >>> incoming WebSocket connections)."
> >>
> >> How will the server know that the client is not capable of being a
> >> WebSocket Server?
> >>
> >> I guess in many cases it might be able to know that because the
> client
> >> is a browser being controlled by scripting from the server. But in
> >> other
> >> cases ISTM that it just won't know.
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >> _______________________________________________
> >> sipcore mailing list
> >> sipcore@ietf.org
> >> https://www.ietf.org/mailman/listinfo/sipcore
> >
> >
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore