This scenario is pretty much possible, As the UE could be a software
component on a device simulating multiple devices at the same time. For
example a Soft client can emulate two devices (two privates)

Contact is only a means of reaching the UE located at particular IP
location; it should not be used as registration key.  We register
Publics (Implicit or explicit) and authenticate the device, for every
authenticated device there is a contact.  

-Dutt


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Vikram
Chhibber
Sent: Monday, February 26, 2007 11:28 PM
To: Jamkhandikar, Sunil
Cc: [email protected]
Subject: Re: [Sip-implementors] SCSCF Registrar functionality

I don't know how this particular scenario can happen. I think there is
nothing wrong if the Contacts are same for same public but different
privates. The only consideration should be that while receiving the
INVITE, it should not be forked on multiple privates ending on same
Contact.

On 2/27/07, Jamkhandikar, Sunil <[EMAIL PROTECTED]>
wrote:
> In the scenario the Contacts are same for both the registrations; my
> query is if the Contacts are same is the registration allowed.
>
> If the Contacts are different SCSCF obviously registers both the
> Register requests.
>
> Thanks,
> Sunil
>
> -----Original Message-----
> From: Gary Cote [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 26, 2007 7:58 PM
> To: Jamkhandikar, Sunil
> Cc: [email protected]
> Subject: Re: [Sip-implementors] SCSCF Registrar functionality
>
> I believe this is allowed.
>
> I seem to recall scenarios where the private id is uniquely assigned
> to the UE. A subscriber could register the same public id from
> multiple devices (e.g. his PDA and cell phone). Each device may have
> different capabilities and some services may be delivered to one
> device or the other, or delivered to both devices.
>
> This is just one possible scenario from memory. There are certain to
be
> others.
>
> Also note that just because the standards say it's possible doesn't
> meant that any particular vendor has implemented it, or any particular
> service provider's policy supports it.
>
> --
> Gary Cote
> www.awardsolutions.com
>
>
> "This email message and any attachments are confidential information
of Starent Networks, Corp. The information transmitted may not be used
to create or change any contractual obligations of Starent Networks,
Corp.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon this e-mail and its attachments by
persons or entities other than the intended recipient is prohibited. If
you are not the intended recipient, please notify the sender immediately
-- by replying to this message or by sending an email to
[EMAIL PROTECTED] -- and destroy all copies of this message
and any attachments without reading or disclosing their contents. Thank
you."
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to