Hi Malleswara,
Comments are inline.
> Can add other cross-overs like Re-INVITE-Re-INVITE (especially when
> both dont carry any SDP), Re-INVITE-UPDATE
Thank you for your comments. I would like to consider to add these examples.
Please give me some time to think about this. I want to think this over.
> Some thoughts:
> In Section 2.1, CANCEL cross over can result in a subsequent BYE from
> the UAC.
In the situation of the CANCEL crossover, the call would be established
nevertheless the onhook state of SIP Phone, when it comes to be in the
situation of a CANCEL crossover. Considering the ordinary telephone, I think
this situation is a problem. According to RFC3261, UA can send BYE message
after the session has been established. So, I think it is a good idea that the
UAC would send BYE automatically just then it receives 200 OK without noticing
to the user. I would like to add the description about sending BYE message to
my draft, considering SIP Phones.
Thank you for your helpful comment.
> In Section 2.2, for BYE cross over, I think that either of the UAs
> can still respond
> with a 200ok assuming that the BYE it had sent was lost and then can stop
> waiting for a response to its BYE (cuz it doesnot make any more sense to
> even
> retry the BYE)
I understood that the issue you pointed out.
I explain clearly by using a following sequence diagram.
Alice Bob
| |
| BYE BYE |
|--------- ----------|
| \ / |
| X |
| / \ |
|<-------- ----> X |
| |
| 200OK |
|----------------------->|
| |
I think the dialog has been terminated when the server sends the BYE message,
so a 200 OK message cannot be sent. It would come to be the sequence flow as
the following:
Alice Bob
| |
| BYE BYE |
|--------- ----------|
| \ / |
| X |
| / \ |
|<-------- ----> X |
| |
| 481 |
|----------------------->|
| |
| BYE |
|------------------> X |
| |
| BYE |
|------------------> X |
| : |
| : |
I think sending BYEs repeatedly is unavoidable, because the client follows the
rule of non-INVITE client transaction described in RFC3261.
Thank you, again.
Regards,
Miki Hasebe
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
