Re: [RFC 4235 & draft-kuthan-sip-derive] 481 "Call doesn't exist" for initial SUBSCRIBE ?
Adam Roach <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
While 403 would be valid if local policy warrants, my reading of 4235 is that an authorized subscriber would start getting NOTIFY messages that contain no dialog information. The dialog identifier is treated as a filter. The application of that filter to the existing dialogs might be an empty set. /a Paul Kyzivat wrote: > 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 _______________________________________________ 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