> Hi All, > > Is there any usecase, where multiple REFER requests would be sent > with a Dialog created by REFER request? > As per the interpretation of RFC 3515, our understanding is as follows: > > > A B C > D > | | | > | > |------REFER(callid1)/202--->| | > | > | |--------INV---------------->| > | > |<-NOTIFY(100 Trying)/200-| | > | > | | | > | > |-------REFER(callid1)/202->| | > | > | > |--------------------------------|-------------INV--------------->| > > |<-NOTIFY(100 Trying)/200-| | > | > | |<-------200------------------| > | > | |-------ACK----------------->| > | > |<-NOTIFY(200 OK)/200-----| | > | > | | | > | > | > |<------------------200-------|-----------------------------------| > | > |--------------------------------|---ACK------------------------>| > |<---NOTIFY(200 OK)/200--| | > | > | | > > Is there any real-time use case for the above scenario? > > If the above use case is possible, that is , if there are multiple REFER > requests in a dialog > (created by first REFER request itself) , then what would be the > behaviour for: > 1) UA (refer recipient)with no support for multiple calls > a)Whether the UA will support such a scenario? > b)if yes, how the the call intiated by the UA(refer recipient) as a > result of first refer , would be handled? > > 2) UA (refer recipient)with support for multiple calls > a)What would be the call flow followed in such a case? > > Thanks, > Pallavi > >
Disclaimer: This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies and its customers, privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
