[SIPForum-discussion] SIP Forking: UAC cancels CALL; call-flow?

[Stephen James]

I assume that you are not doing the forking, but a downstream forking proxy.
Per RFC 3261 the CANCEL is sent to the same location as the INVITE, so only one 
CANCEL should be sent.


The destination address, port, and transport for the CANCEL MUST be identical to 
those used to send the original request.
Also,


The following procedures are used to construct a CANCEL request.  The    
Request-URI, Call-ID, To, the numeric part of CSeq, and From header    fields in 
the CANCEL request MUST be identical to those in the    request being cancelled, 
including tags. 


Since the To header has the same tags as the INVITE (no tag) then there wouldn't 
be 

any way to address the individual early dialogs.


 
Stephen James 
sjames_1958 at yahoo.com
 
We are not princes of the earth, we are the descendants of worms, and any 
nobility must be earned.





________________________________
From: Anurag Somani <somani7anurag at gmail.com>
To: discussion at sipforum.org
Sent: Fri, March 9, 2012 6:29:26 AM
Subject: [SIPForum-discussion] SIP Forking: UAC cancels CALL; call-flow?


Hi,
 
I had a question regarding SIP Parellel Forking. 
Suppose I have got multiple 1xx response from different forked AOR. These 1xx 
dialogs have established an early-dialog.

Now If the UAC cancels the call, should we send a CANCEL request to all the legs 
or only to one?
In case we send it to only one leg, will the server CANCEL the remaining legs. I 
cannot find anything in the RFC for greater clarity.
 
Regards,
Anurag

-- 
Against the practice of sensational journalism in India:
"I'm all in favor of keeping dangerous weapons out of the hands of fools. Let's 
start with typewriters."
    - Frank Lloyd Wright
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20120309/0377ae04/attachment-0002.html>