In fact I agree that's a bug -- the SUBSCRIBE is supposed to create a dialog
on its own and it is not denied because of an absent dialog context, but
because Alice has no reason to accept unsolicited subscribes.
Which touches the delicate privacy aspect -- how do we make sure that
the NOTIFY requests disclose only status to a rightful recepient
(i.e., the callee).
-jiri
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
