A plausible case is when the call is forked, and there are 180 responses
from multiple forks. The UAC may then be able to determine from the
answer SDP that one of the early dialogs is undesirable - lacks features
it wants. So it sends a BYE to that one while allowing the other to
continue ringing.
For instance, this might be the case if the offer was audio/video, and
one of the answers has only audio while the other has both. If video is
*really* important on this call (e.g. because the caller is deaf) then
this might be a reasonable behavior.
Thanks,
Paul
kishore sowdi wrote:
> Hi,
> Section 15 of RFC 3261 says - "The caller’s UA MAY send a BYE for
> eitherconfirmed or early dialogs, and the callee’s UA MAY send a BYE
> onconfirmed dialogs, but MUST NOT send a BYE on early dialogs".
> Section 12.1 of RFC 3261 says - "A dialog established by a non-final response
> to a request is in the "early" state and it is called an early dialog".
> Section 9.1 of RFC 3261 says - "If no provisional response has been received,
> the CANCEL request MUST NOT be sent; rather, the client MUST wait for the
> arrival of aprovisional response before sending the request. If the original
> request has generated a final response, the CANCEL SHOULD NOT be sent, as it
> is an effective no-op, since CANCEL has no effect on requests that have
> already generated a final response".
> So , How In early dialog state can UAC send BYE?
>
> I want to know the used case when caller's UA will send a BYE for a early
> dailog case.
>
> Regards,Kishore
>
>
> Explore and discover exciting holidays and getaways with Yahoo! India
> Travel http://in.travel.yahoo.com/
> _______________________________________________
> 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
