Hi To solve this problem we could use the mechanism defined in RFC 4488 - Suppression of SIP Refer method Implicit subscription. So here when the UAC i.e the REFER Issuer is sending the 2nd REFER request, it can follow the procedures defined in above RFC so that the REFER recipient does not create another implicit subscription for the REFER request. But here too it is not clear how the REFER issuer would know if the REFER recipient supports RFC 4488 or not - unless REFER recipient inserts the mentioned option-tags in the response to first REFER request -- because if it does not, then implicit subscription is anyway created for 2nd REFER request too as per RFC 3515.
Regards Ranjit ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vavilapalli Srikanth-A19563 Sent: Friday, July 25, 2008 11:37 AM To: [email protected] Subject: [Sip] RFC 3515: Multiple REFER Requests in a Dialog - Needclarification Hi I have seen some discussion happened on this topic in the following mail trail, but still not clear with one thing: https://lists.cs.columbia.edu/pipermail/sip-implementors/2003-December/0 05829.html Is there any use case where we receive second REFER message that creates a subscription while there exists an already an 'active' REFER subscription in the same dialog? RFC 3515 has given a use case by saying that "If more than one REFER is issued in the same dialog (a second attempt at transferring a call for example)". But in the above scenario, I assume that the first attempt to call transfer has failed (i.e. first REFER subscription terminated). Please clarify me. Regards Srikanth
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
