Re: [Sip-implementors] UA receives next reliable 180 before the 200OK of PRACK

"JC" writes: > There is one SIP call scenario that one SIP UA sends one reliable 183 to one > SIP device, and the UA receives the PRACK, then, it sends 200OK of PRACK and > one new reliable 180 immediately. All the messages are sent over UDP, due to > the network issue, the SIP

Re: [Sip-implementors] Reuse of established TCP connection for in-dialog requests

Paul Kyzivat writes: >> The larger system-design questions are worth considering. If the DNS >> for edge.test.com is adjusted to give higher priority to proxy2, doesn't >> that mean that the administrator *really wants* all new requests to go >> to proxy2 if possible?

Re: [Sip-implementors] Query in handling 180 response by proxy

Hi, The proxy would relay 18x responses from both locations. RFC 5359 section 2.9 shows a related example for Call Forwarding No Answer. > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of

Re: [Sip-implementors] Reuse of established TCP connection for in-dialog requests

On 3/15/16 8:03 AM, ankur bansal wrote: Hi Paul Please explain more about what you are asserting for TLS. It looks wrong to me, but I'm not sure I understand what you are trying to say. I was trying to point to RFC 5923 which provides provision to reuse same TLS connection not only for

[Sip-implementors] Query in handling 180 response by proxy

Hi All, If an Invite request is received to a proxy, proxy then forks the Invite message to two destinations. 180 Ringing Response is received from both the destinations to the proxy. Proxy is now forwarding both 180 Response to the request originator. Is this right behavior of proxy or it

Re: [Sip-implementors] Reuse of established TCP connection for in-dialog requests

> On 15 Mar 2016, at 13:38, Brett Tate wrote: > > Hi, > >>> As far as I know, the main complaint is that it can >>> temporarily prevent/delay honoring the DNS configured load >>> balancing and priorities. >> >> So there is a consensus that transaction based DNS load >>

Re: [Sip-implementors] UA receives next reliable 180 before the 200OK of PRACK

Hi Ankur, Question is to handle next reliable 180 (provisional) response. Regards, Mohit On 3/15/16, ankur bansal wrote: > Hi Mohit , > > The phrase you mentioned mostly refers to scenario where Rseq not in > sequence then next prov response should be cached/discarded. >

Re: [Sip-implementors] Reuse of established TCP connection for in-dialog requests

Hi, > > As far as I know, the main complaint is that it can > > temporarily prevent/delay honoring the DNS configured load > > balancing and priorities. > > So there is a consensus that transaction based DNS load > balancing is more preferable to the dialog based TCP > connection reuse? Meaning

Re: [Sip-implementors] UA receives next reliable 180 before the 200OK of PRACK

Hi Mohit , The phrase you mentioned mostly refers to scenario where Rseq not in sequence then next prov response should be cached/discarded. But original question here is if next prov response should be handled by UAC in case it lands before 200ok PRACK of last response. Correct me if don't

Re: [Sip-implementors] Reuse of established TCP connection for in-dialog requests

Hi Paul >>>Please explain more about what you are asserting for TLS. It looks wrong to me, but I'm not sure I understand what you are trying to say. I was trying to point to RFC 5923 which provides provision to reuse same TLS connection not only for sending Requests from Caller(A) but also for

Re: [Sip-implementors] Reuse of established TCP connection for in-dialog requests

Hi, >As far as I know, the main complaint is that it can temporarily prevent/delay >honoring >the DNS configured load balancing and priorities. So there is a consensus that transaction based DNS load balancing is more preferable to the dialog based TCP connection reuse? Meaning that is

Re: [Sip-implementors] UA receives next reliable 180 before the 200OK of PRACK

Hi, RFC3262 states following under section 4 "UAC Behaviour" "Handling of subsequent reliable provisional responses for the same initial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be in order. As a result, if the UAC

[Sip-implementors] UA receives next reliable 180 before the 200OK of PRACK

Hi, There is one SIP call scenario that one SIP UA sends one reliable 183 to one SIP device, and the UA receives the PRACK, then, it sends 200OK of PRACK and one new reliable 180 immediately. All the messages are sent over UDP, due to the network issue, the SIP device receives the 2nd