[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] is there a way to specify that far end sip server should use reliable transpo
From:       Paul Kyzivat <pkyzivat () cisco ! com>
Date:       2006-01-24 19:11:03
Message-ID: 43D67BC7.8060902 () cisco ! com
[Download RAW message or body]

I believe that you may get retransmissions if any hop is unreliable. And 
it is difficult to guarantee that all hops are using reliable transport. 
The closest thing I know of to that is to use SIPS URIs. But even then 
the path from the proxy supporting the destination address and the UA at 
that end need not be reliable - it must only be secure.

So unless you are working in a walled garden where you can control all 
the nodes I think you are out of luck.

Why do you want to create a new simplified new UA rather than adopting 
an existing (not so simplified) UA?

	Paul

MEENA SELVAM wrote:
> Hi,
> 
> I am writing a simplified SIP UA (nota full fledged
> SIP UA) to meet our requirements. To keep it simple my
> SIP UA (acting similar to a SIP phone) will only
> implement reliable transport.
> 
> If I want to have simple implementation (avoiding
> processing repeated retransmissions of say OK from the
> far end server, ) is there a way to specify that the
> far end should use reliable transport, say as part of
> INVITE. In the RFC, I do not see anything explicit in
> any of the INVITE headers?
> 
> In general, in a UA stack implementation , that
> supports both reliable and unreliable transport, which
> is the entity that drives to choose which one be used?
> 
> Meena
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> 

[prev in list] [next in list] [prev in thread] [next in thread]