Subject: [Sipping] RE: [Sip-implementors] Semi Regular Examples draft

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 10 Mar 2005 17:30:59 -0500

Maybe the doc should clearly say "this is the problem (or confusing)
scenario" and this is the best practice to handle it. On a cursory read, I
thought that might help in making it more readable.

-Medhavi.

> -----Original Message-----
> From: [email-masked] [mailto:sip-implementors-
> [email-masked]] On Behalf Of Jun KOSHIKO(Private)
> Sent: Thursday, March 10, 2005 12:35 PM
> To: [email-masked]; [email-masked]
> Cc: Cullen Jennings; Gonzalo Camarillo; 'Dean Willis'; Hasebe Miki
> Subject: [Sip-implementors] Semi Regular Examples draft
> 
> Folks,
> 
> We are now doing new examples work, as chairs announced on SIPPING WG
> meeting on Thursday morning.
> 
> The draft can be found at
>
http://www.ietf.org/internet-drafts/draft-hasebe-sipping-semi-regular-exampl
es-00.txt
> 
> This draft gives examples of SIP semi-regular call flows. We would like
> to clarify less ordinary call flows or corner cases, such as the call
> flow in which a BYE from UAC and UAS crosses each other.
> 
> Followings are our purposes:
> - To help implementation or testing of SIP, by describing the plain
>   examples about difficult parts of RFCs.
> - Improvement in interconnectivity by minimizing the difference between
>   implementers to clarify the behaviors.
> 
> We would like to ask you followings:
> - Please review the draft
> - Send additional examples to authors
> - Better idea for title?
>   (We think the title "Semi Regular examples" could be better.)
> 
> Five examples are included in 00 version. And we would like to accept
> additional examples. We also appreciate your comments to existing
> examples.
> 
> Any comments and thoughts are appreciate.
> 
> Regards,
> Jun Koshiko
> 
> _______________________________________________
> Sip-implementors mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Jun KOSHIKO(Private)" <[email-masked]>
Date: Sat, 12 Mar 2005 03:13:43 -0600

Thank you for your comment. I agree and I'll modify the abstract and/or
introduction based on your suggestion. There leaves much to be improved,
but we would like this example work to be a good one. We appreciate your
comments or thoughts.

Thank you.
Jun Koshiko
NTT-East Corporation, Japan

---

From: Kenneth Ho <[email-masked]>
Date: Tue, 15 Mar 2005 02:20:49 -0800

Hi Jun,

Section 2.1 CANCEL crossover - describes when an UAS sends a final 
response to an INVITE, the INVITE transaction is not there on the UAS 
anymore. Consider these scenarios:
1. An UAS receives an INVITE, but response(s) sent to the UAC failed to 
be delivered, the UAS receives a retransmission of the INVITE which it 
200ed. Instead of processing the INVITE retransmission in a new 
transaction, it makes more sense if the UAS keep the transaction around 
(until transaction timeout?) and retransmits the 200 upon receiving 
INVITE retransmission. In other words, when an dialog on UAS is in 
confirmed dialog state doesn't imply the INVITE transaction has gone away.
2. Suppose Alice is using a SIP phone, she calls Bob and hangs up. As 
the draft described, Alice's CANCEL crosses Bob's 200. The draft 
suggests Alice's INVITE succeeded and two way media path is established, 
but Alice's phone is hung up, how does it work?

Please consider these two alternatives:
1. When an UAS receives a CANCEL to an INVITE which it has 200ed, it 
should assume the 200 was dropped, then 200s the CANCEL and then 487s 
the initial INVITE. Accordingly, UAC should treat any follow-up 
provisional/final response to its INVITE as stray response, ignore it, 
once it CANCELed the INVITE or
2. When an UAC receives a 200 to an INVITE which it has CANCELed, both 
UAC and UAS proceed as the draft described. In addition, UAC sends a BYE 
immediately after ACKing the 200. As far as Alice (user of the UAC) is 
concerned, once she hangs up, all dialogs and all sessions created as a 
result of its INVITE are terminated, if any. However, UAC core and 
transaction layer should keep the contexts around to handle potential 
retransmissions. Perhaps this is implied in the draft, if so, I suggest 
making it explicit.

Ken Ho

Jun KOSHIKO(Private) wrote:

>http://www.ietf.org/internet-drafts/draft-hasebe-sipping-semi-regular-examples-00.txt
>

---

From: Malleswara Rao Ankem <[email-masked]>
Date: Thu, 17 Mar 2005 11:23:07 +0530

Can add other cross-overs like Re-INVITE-Re-INVITE (especially when both dont  
 carry any SDP), Re-INVITE-UPDATE 
 Some thoughts:
  In Section 2.1, CANCEL cross over can result in a subsequent BYE from
  the UAC. 
  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)