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

List:       sip-implementors
Subject:    Re: [Sip-implementors] How to detect Spiral scenario in Case of CANCEL .
From:       Robert Sparks <rjsparks () nostrum ! com>
Date:       2008-12-25 17:07:50
Message-ID: EAC93171-E4B0-4AD5-8442-AB840A5302EF () nostrum ! com
[Download RAW message or body]

So what is your actual question? Are you wanting to know _why_ your  
Proxy 1 isn't generating a CANCEL towards UA3?
If so, you need to provide more information to get any help here -  
specifically, what is the topmost branch of the INVITE that
went from proxy 2 to proxy 1, and does that match the single branch in  
the CANCEL between those elements? Has UA3
responded to Proxy 1 in any way (if it hasn't, Proxy 1 is forbidden to  
send the CANCEL towards it).

Proxy1 being call stateful is not relevant to the question above, so  
I'm not sure that's what you're asking about.

Some important points inline still:

On Dec 24, 2008, at 3:50 AM, Ashish Dobhal wrote:

>
> Hi Robert,
>      Thanks for your reply.
>
> Let me elaborate the problem further.
>
> Proxy1 is a Call State full proxy.
>
> INVITE Flow:
>
> UA1 ---> Proxy 1 ---> Proxy 2 --> Proxy 1 --> UA3
>             |
>
>             | ----> UA 2
>
> So when UA 2 accepts the call, Proxy 1 tries to CANCEL the other  
> forked Location by sending the CANCEL to Proxy 2. Since Proxy 2 sent  
> the INVITE to Proxy 1 previously it will sends the CANCEL
Be very careful with the work "the" here. The CANCEL Proxy 2 sent to  
Proxy 1 is _NOT_ a forwarded version of the CANCEL Proxy 2 received.
The logic at Proxy 2 issued its _own_ CANCEL on a client transaction  
branch it was managing in a response context when it received a CANCEL  
on that context's server transaction.
> to Proxy 1 again, which Proxy 1 should send it
Proxy 1 will, in turn, should generate a _different_ CANCEL.

> to UA3 to CANCEL the Invite transaction at UA3.
>
> CANCEL Flow:
> Proxy 1 ---> Proxy 2 --> Proxy 1 ---X--- UA3
>
> Proxy 1 sends the CANCEL to Proxy 2, which respond with 200 OK to  
> Proxy 1.
> Proxy 2 then sends the CANCEL to Proxy 1, however Proxy 1 fails to  
> detect it as a Spiral Request.
What makes you say that?
> Hence pass this INVITE to application sitting on SIP stack at Proxy  
> 1 statelessly even though Proxy1
> is call statefull.
You were talking about the CANCEL - the INVITE is long gone already,  
so this last sentence is very confusing.
>
>
> Regards
> Ashish
>
> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]
> Sent: Wednesday, December 24, 2008 11:50 AM
> To: Ashish Dobhal
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] How to detect Spiral scenario in  
> Case of CANCEL .
>
> See responses inline:
>
> On Dec 23, 2008, at 11:31 PM, Ashish Dobhal wrote:
>
> > Hi All,
> >
> >   I have a query related to Spiral Scenario for CANCEL which is a  
> hop
> > by hop request.
> >
> >
> >
> > Scenario:
> >
> > User Agent 1(UA1) Forward the INVITE to PROXY1. PROXY1 forked it  
> to 2
> > locations UA2 and PROXY2.
> >
> > PROXY2 Forwards the INVITE to PROXY1 again (INVITE is a Spiral  
> request
> > on Proxy 1).
> >
> > Proxy1 forwards it to UA3.
> >
> > UA3 and UA2 ringing and 180 received by Proxy1. UA2 picks Up the  
> call
> > and sends 200 OK to Proxy1.
> >
> >
> >
> > Proxy1 Generates CANCEL for other Location (in our Case Proxy2) and
> > forwards to Proxy2.
> >
> > Proxy2 responses with 200 OK (as CANCEL is hop by hop request) to
> > Proxy1
> > and forwards the CANCEL to
> >
> > Proxy1 for forwarding CANCEL to UA3.
> >
> >
> >
> >
> >
> > Question:
> >
> > How will PROXY1 will come to know that CANCEL received from PROXY2  
> is
> > for Spiral request
> The single Via in the CANCEL will match the topmost Via from the  
> INVITE
> > and
> >
> > it should be forwarded to UA3.
> CANCEL is never forwarded (at least by transaction stateful proxies)
> As you note above, CANCEL is hop-by-hop.
> The information in the response-context matching that Via branch
> parameter will determine whether your PROXY1 will
> do anything based on having received that CANCEL.
>
>
> If that doesn't answer your question, please restate it.
>
> >
> >
> >
> >
> >
> >
> > Thanks and Regards
> >
> > Ashish
> >
> >
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>


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