Hi Jan ,
First of all let me clarify diff between CANCEL and BYE ,then we will be in
better position to understand what to use when ..
As you know multiple early dialogs might be present due to forking
1. BYE is sent to terminate a specific dialog(early or confirmed) as to-tag
present in BYE
CANCEL is sent to terminate all early dialogs created for the INVITE
for which CANCEL is sent ,as to-tag not present
2. BYE is sent for a dialog ...it means sending BYE does not mean INVITE
transaction cleanup ,we still need final response for INVITE txn
CANCEL is sent for INVITE
So its the forking scenario ,where BYE could be be sent instead of CANCEL
to terminate a specific early dialog .
Lets take example User A calls B ,but proxy forks the request to B1 B2 so
both B1 B2 ringing & send 180 with diff to-tags
But User A(caller preference) prefers UserB1 to answer the call so user A
can trigger BYE to User B2 with its specific to-tag.
Thanks & regards
Ankur Bansal
On Tue, Oct 8, 2013 at 12:45 PM, Jan Bollen <jan.bol...@scarlet.be> wrote:
> Hello,
>
> The question is: where is the "pending" request in the presented scenario
> with the BYE sent in a early dialogue.
> The same RFC also states:
> "The notion of "hanging up" is not well defined within SIP. It is
> specific to a particular, albeit common, user interface.
> Typically, when the user hangs up, it indicates a desire to
> terminate the attempt to establish a session, and to terminate any
> sessions already created. For the caller's UA, this would imply a
> CANCEL request if the initial INVITE has not generated a final
> response, and a BYE to all confirmed dialogs after a final
> response."
> So I wonder under what circumstances a BYE would be sent instead of a
> CANCEL when the INVITE has not resulted in a session yet.
>
> Kind regards,
> Jan
>
> On 7/10/2013 13:30, Preksha Gupta wrote:
>
> Hi Pravin
>
> It is recommended for UAS to send 487 for pending requests in such
> scenarios.
> Refer Section 15.1.2 of RFC 3261:
>
> " The UAS MUST still respond to any pending requests received for that
> dialog. It is RECOMMENDED that a 487 (Request Terminated) response be
> generated to those pending requests."
>
> Regards
> Preksha<http://tools.ietf.org/html/rfc3261#section-15.1.2>
> <http://tools.ietf.org/html/rfc3261#section-15.1.2>
>
>
> On Mon, Oct 7, 2013 at 4:49 PM, Pravin Kumar <pravink...@gmail.com>
> <pravink...@gmail.com> wrote:
>
>
> According to RFC 3261:
> Early Dialog can be terminate sending by BYE or CANCEL for UAC side.
> In case of CANCEL we should send 487 for INVITE
>
> UAC UAS
>
> ---------INVITE--------------------->
> < ---------180----------------------
> ----------CANCEL----------- >
> < ---------200 CANCEL-------
> < -----------487 ---------------
> ------------ACK 487----------->
>
> But in the of BYE:
>
> UAC UAS
>
> -------INVITE----------------->
> < ---------180-----------------
> ----------BYE ---------------- >
> < ---------200 BYE -----------
> <--(what should be send)----- (503 or 487)
> ------------ACK ------------->
>
> So in the case of sending BYE by UAC , UAS should send 503 or 487 for
> INVITE.
>
> Thanks,
> Pravin
> _______________________________________________
> Sip-implementors mailing
> listsip-implement...@lists.cs.columbia.eduhttps://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
