Re: [RFC 4235 & draft-kuthan-sip-derive] 481 "Call doesn't exist" for initial SUBSCRIBE ?
Paul Kyzivat <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
I agree that 481 seems an unsuitable response in this case. Its not clear to me what response is best suited. Perhaps 403 or 603. Thanks, Paul Iñaki Baz Castillo wrote: > Hi, I've a doubt about what should be the correct response for an initial > SUBSCRIBE (Event: dialog) if the indicated dialog doesn't exist in the > recipient of the SUBSCRIBE. > > This doubt comes after reading the today submitted draft "Dialog Event foR > Identity VErification": > http://www3.ietf.org/proceedings/staging/draft-kuthan-sip-derive-00.txt > > In page 14 of this draft there is a flow about a suspicious call (spoofed > From). The flow is correctly displayed using fixed length typography, if it's > not your case refer to page 14 of the draft. > > > Attacker Alice Proxy 1 (atlanta.com) Proxy 2 (biloxi.com) Bob > | | INVITE F5 | | | > |------------------------------------------------>| | > | | 100 F6 | | | > |<------------------------------------------------| INVITE F7 | > | | | |--------------->| > | | | | 100 F8 | > | | | |<---------------| > | | | | SUBSCRIBE F9 | > | | | SUBSCRIBE F10 |<---------------| > | | SUBSCRIBE F11 |<---------------| | > | |<---------------| | | > | | 481 F12 | | | > | |--------------->| 481 F13 | | > | | |--------------->| 481 F14 | > | | | |--------------->| > > > So, Bob sends an initial SUBSCRIBE to Alice AoR (the received From uri in the > INVITE F5/F7) with the half-dialog data: > > SUBSCRIBE sip:[email protected] SIP/2.0 > From: Bob <sip:[email protected]>;tag=8672349 > To: <sip:[email protected]> > Call-ID: [email protected] > Contact: <sip:[email protected]> > Event: dialog;[email protected];to-tag=9fxced76sl > Expires=0 > Accept: application/dialog-info+xml > Content-Length: 0 > > Note that "Event" header contains specific half-dialog information. > > This SUBSCRIBE arrives to Alice's UA which is not aware of that dialog. Which > response should it reply? The flow suggests "481 Call/Transaction doesn't > exist", but... is it correct? > > AFAIK, a 481 should be replied when an *in-dialog* request arrives to an UAS > which is not aware of that dialog. But in the above case we have an *initial* > request and the 481 refers to the specific dialog in the "Event" header. > > > Well, I suggest a possible issue with the above behaviour: > > - Alice invites Bob. > - Before sending a provisional response, Bob sends an *initial* SUBSCRIBE to > Alice with the current half-dialog information in the "Event" header. > - Alice accepts the SUBSCRIBE, replies 200 and later a NOTIFY with the > specific dialog status. > > a) > - After 40 seconds Alice's UA crashes and is restarted (dialog info lost). > - Bob sends a SUBSCRIBE refresh (an in-dialog request). > - That dialog (the SUBSCRIBE dialog) doesn't exist in Alice anymore, so Alice > replies 481. > > b) > - Dialog between Alice and Bob ends because Alice sends a BYE, but before > Alice receives the BYE and the dialog NOTIFY update, Bob sends a SUBSCRIBE > refresh (an in-dialog request) for that dialog. > - This SUBSCRIBE arrives to Alice, the SUBSCRIBE request dialog exists but the > dialog indicated in "Event" header doesn't exist anymore. > - As the above flow suggests, Alice replies 481. > > In both cases a) and b), Alice replies 481 but the scenario is completely > different. The 481 in a) means that the in-dialog SUBSCRIBE belongs to a non > existing dialog in Alice, while the 481 in b) means that a dialog indicated > in the Event header doesn't exist. > But there is no way for Bob to realize which is the case a) or b). > > > The main question is: is 481 the approiate (and valid) reply in the above flow > (case b)? Is 481 really valid as a reply for an initial request? > > > > _______________________________________________ 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