On 11/7/12 10:42 AM, Jānis Rukšāns wrote:
> On Wed, 2012-11-07 at 15:00 +0000, Brett Tate wrote:
>>> Is the SUBSCRIBE request can have the multiple contact headers?
>>
>> No. See RFC 3261 section 8.1.1.8.
>>
>> "The Contact header field MUST be present and contain exactly one SIP
>> or SIPS URI in any request that can result in the establishment of a
>> dialog."
>
> And what about RFC 6665 section 4.4.1:
>
> 'Dialogs usages are created upon completion of a NOTIFY transaction
> for a new subscription, unless the NOTIFY request contains a
> "Subscription-State" of "terminated."'
>
> 'Because the dialog usage is established by the NOTIFY request, the
> route set at the subscriber is taken from the NOTIFY request itself, as
> opposed to the route set present in the 200-class response to the
> SUBSCRIBE request.'
>
> The way I read that is that it's the NOTIFY that establishes the dialog,
> not 2xx to SUBSCRIBE.
This is a weird case. In 3265 SUBSCRIBE was dialog-establishing. This
was revised in 6665. In reality, dialogs aren't established by request
message - they are established by a couple of messages in opposite
directions. In simple cases these are a request and its response that
form a transaction. (E.g. INVITE/2xx.)
But 3265 extended this. In addition to the SUBSCRIBE/2xx forming a
dialog, SUBSCRIBE/NOTIFY/2xx(NOTIFY) could also establish a dialog. This
caused confusion because the 2xx to the SUBSCRIBE and the first NOTIFY
could both be establishing the same dialog, and it was confusing which
did it and when. So 6665 chose to clarify that the it was the NOTIFY,
and not the 2xx to the SUBSCRIBE, that created a dialog.
But still, the SUBSCRIBE supplies the subscriber's contact, callid, and
from tag for every one of the dialogs, even though the NOTIFY, rather
than the 2xx that supplies the notifier contact and to-tag.
So, practically speaking, SUBSCRIBE is still dialog establishing with 6665.
Adam (as author of 6665) may chime in and say more, or correct me.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
