knarayan wrote:
> Depends on what is the deployment network.
Yes.
> RFC 3455( specifically for the IMS network) tried to address this using an
> independent header in case you support implicit registrations of one AOR if
> the other AOR is Registered or when the contact registered is the same for
> both the AORs.
IMS presents some interesting challenges for this kind of feature.
If both AORs are part of the same subscriber entry, then it isn't too
much of a problem. (Will comment on that further below.)
It is however more of a problem if the two "lines" are represented as
independent subscribers. (For instance, consider the case where one line
represents the "boss" and the other represents the "secretary", and they
have independent subscriptions.) IMS doesn't permit third party
registrations, where From and To are different. So it wouldn't permit
the secretary to register to the boss' AOR.
> However this Requires support in the Client and Server (to populate/read and
> display). I
>
> P-Called-Party-id : The URI in the Request line before it was replaced by the
> registered contact for routing to the registered user.
If you assume one "subscriber" entry, with two Private User IDs and two
Public User IDs, then it can work in IMS with/without implicit
registration. Probably you don't want implicit registration in this case.
So, the boss' public user id is set to allow registration using either
the boss' or secretary's private user id. The secretary's public user id
is set to allow registration only using the secretary's private user id.
The boss registers once, using the corresponding public user id as both
From and To, and the boss's private user id.
The secretary registers twice:
- once using the secretary public user id as from and to, and the
secretary's private user id.
- once using the boss' public user id as from and to, and the
secretary's private user id.
In normal IMS tradition, the secretary would probably use the same
contact address for both registrations. The UE would be able to
distinguish which public user id was targetted on incoming calls by
looking at the P-Called-Party-ID header in the incoming request. It can
then do the right thing with the display.
This kind of scheme could be workable in this boss secretary setup as
long as the secretary has only one boss. If the secretary has many
bosses, and they are independent subscribers, then it doesn't work so
well. It can still be made to work by giving the secretary multiple
private user ids.
Paul
> Kasturi
>
>
> On Friday 14 April 2006 21:53, Paul Kyzivat wrote:
>
>>I would expect that the phone would be provisioned with two AORs that it
>>registers to - one for the personal line and one for the call center
>>line. When the phone registers, it uses a different contact uri for each
>>line. E.g:
>>
>> REGISTER sip:example.com
>> To: sip:[EMAIL PROTECTED]
>> From: sip:[EMAIL PROTECTED]
>> Contact: sip:[EMAIL PROTECTED]
>>
>> REGISTER sip:example.com
>> To: sip:[EMAIL PROTECTED]
>> From: sip:[EMAIL PROTECTED]
>> Contact: sip:[EMAIL PROTECTED]
>>
>>Incoming calls will be addressed to the contact corresponding to the AOR
>>corresponding to one of the "lines". The phone can use this info to
>>manage the display, etc.
>>
>> Paul
>>
>>Kedar Karmarkar wrote:
>>
>>>Thanks, the example was the exact scenario. I have a related question.
>>>Typically, for an agent in the pre-SIP world, the switch would provision
>>>a special line as an agent, and an agent phone would typically have two
>>>lines, a personal line and a call center line. In that case the switch
>>>knows what call it is sending to the phone and hence can update its
>>>displays accordingly ( e.g. "Missed call" etc.). If this happens to be a
>>>SIP line, is it possible for a UAS figure out what type of line it has
>>>received a call and to modify behaviour accordingly?
>>>
>>>Kedar
>>>
>>>
>>>On 4/12/06, *Paul Kyzivat* <[EMAIL PROTECTED]
>>><mailto:[EMAIL PROTECTED]>> wrote:
>>>
>>> Take a look at RFC 3326 - the Reason header. It even has an example
>>> covering your case.
>>>
>>> Paul
>>>
>>> 이성우 wrote:
>>> > Dear,
>>> >
>>> > I am implementing a Group Ring facility in a small-sized IP-PBX
>>>
>>> system that uses
>>>
>>> > 3 user agents internally. I wonder how I can mark a group ring
>>>
>>> INVITE message to
>>>
>>> > differentiate other normal INVITE message? This is for clearing
>>>
>>> 'missied call' log
>>>
>>> > at all other user agents except for the one that actually
>>>
>>> received the call.
>>>
>>> > Current Scenario is as followings.
>>> >
>>> > 1. Each user agent in IP-PBX system is set to a group ring
>>> > function. 2. There comes a SIP INVITE message from outside to
>>> > IP-PBX system. 3. IP-PBX system forwards the INVITE message to
>>> > each user agent
>>>
>>> that are in the same ring group.
>>>
>>> > 3. Each 3 user agent makes a ring responding 180 message each.
>>> > 4. One user agent receives and send 200 OK back to the caller
>>>
>>> (IP-PBX system).
>>>
>>> > 5. Now that IP-PBX knows it received an answer from a user agent,
>>>
>>> it sends CANCEL to other user agents.
>>>
>>> > 6. Each of the 2 user agents process the CANCEL message leaving
>>>
>>> 'missed call' log in its LCD window.
>>>
>>> > Caller UA IP-PBX UA1 UA2 UA3
>>> >
>>> > | INV | | | |
>>> > |----------------->| INV | | |
>>> > |
>>> > | |--------------->| | |
>>> > | | INV | | |
>>> > | |----------------------->| |
>>> > | | INV | | |
>>> > | |------------------------------>|
>>> > | | 180 | | |
>>> > | |<---------------| | |
>>> > | | 180 | | |
>>> > | |<-----------------------| |
>>> > | | 180 | | |
>>> > | |<------------------------------|
>>> > | | 200 | | |
>>> > | |<---------------| | |
>>> > | | ACK | | |
>>> > | |--------------->| | |
>>> > | | CANCEL | | |
>>> > | |----------------------->| |
>>> > | | CANCEL | | |
>>> > | |------------------------------>|
>>> >
>>> > My questions are
>>> > Q1. How can I let the user agents know that the incomming INVITE
>>>
>>> message is group-call?
>>>
>>> > Q2. If I use a specific SIP Header in the INVITE message (from
>>>
>>> IP-PBX to UAs) to carry
>>>
>>> > the group-call infomation, what header should I use and how?
>>> > Q3. Can I use the specific SIP Header in CANCEL message instead
>>>
>>> of INVITE for the same purpose?
>>>
>>> > Thanks in Advance.
>>> >
>>> >
>>> >
>>> > Lee, Sungwoo
>>> >
>>> > OfficeServ Development/VoIP
>>> > Telecommunication System Div.
>>> > Samsung Electronics Co., LTD.
>>> >
>>> > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>>> > TEL: 82-31-279-4329
>>> > FAX: 82-31-279-2296
>>> > Mobile: 82-10-3015-4329
>>> >
>>> > _______________________________________________
>>> > Sip-implementors mailing list
>>> > [email protected]
>>>
>>> <mailto:[email protected]>
>>>
>>> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> [email protected]
>>> <mailto:[email protected]>
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>> <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
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
