SOURABH ANPAT wrote:
> Hey All
>
> So here is the scenario,
>
> If party A calls party B and party B has a mobile phone, desk phone and
> PC, the call will get forked to all devices and the PC may answer. The
> GRUU for B's PC is stored on device A.
It could be stored by A, for some time and some purposes.
But A must understand that it is indeed holding a reference to a
*device*, and it might not be suitable for all purposes. It surely
shouldn't be used as a substitute for the AOR (B) for arbitrary purposes.
> If B had a sequential ringing
> scheme whereby the mobile phone rang first, then the desk phone, then
> the PC, then this scheme would be lost at the next time that party A
> called party B,
it might not be "lost". They both might be remembered, for use in
particular applications where they are appropriate.
> as the party A may decide to insert the GRUU for the
> next communication with party B, thus contacting the PC. This would
> override any ringing/contacting preferences for party B.
I wouldn't characterize this as overriding the ringing preferences of B.
B in fact hands this contact out for certain kinds of usage, and is
expecting to have it used for certain kinds of things. For instance, its
use in a transfer is one where B's "ring preferences" have no relevance.
But you are right that A may choose to use the contact it has discovered
for a purpose that B considers inappropriate. B may use the grid
parameter in the gruu to help figure out whether the use of a gruu is
appropriate or not.
But I suspect in most cases if A uses the gruu in an inappropriate
context it will be hurting itself as much or more than it is hurting B.
> So that is the background for this question. The question I pose is:
>
> * If the network decides to 'override' the GRUU usage by enforcing
> the ringing preferences for party B,
I consider this something that SHOULD NOT be done. But will consider for
the sake of the argument.
> then the network may Hold the
> communication between party A (using party B GRUU) and notify party A of
> unavailability to complete the communication path based on existing
> callee capabilities i.e. using party B GRUU.
I don't know what you mean by "hold the communication". If I guess you
are suggesting that the proxy responsible for B may return an error when
the B-gruu is used, rather than completing the call to the associated UA.
> Party A may then
> re-initiate (using SIP UPDATE) communication with party B by not
> including party B GRUU.
I take back what I just said above. I guess you are suggesting something
new - that the proxy return a 1xx response that signifies that the call
will not be completed as-is, and must be retried via an UPDATE????
That is just bizarre, and violates all the semantics of dialogs, etc.
You don't explain under what circumstances the proxy might choose to do
something like this. It would seem to undermine the entire purpose of gruu.
> * Is it possible to use UPDATE in such a manner to change the
> Contact header within the Invite dialog?
You may use UPDATE to change the contact header, but probably not as you
have in mind.
The UPDATE can't be used until you have an early dialog. A new 1xx error
for this purpose would of necessity establish an early dialog between
the UAC and the "proxy". Then the UPDATE would travel within that early
dialog and update its contact. It wouldn't affect any other dialogs.
But in that case a dialog has been established to the "proxy", which is
then acting as a UAS. It will then not be allowed to proxy the UPDATE to
some "real" UAS.
You might be able to make this work with a B2BUA rather than a proxy.
But WHY? I don't vaguely get what you are trying to achieve.
Maybe if you spelled out the behavior you are tryi8ng to achieve.
Paul
> Regards
>
> Sourabh Anpat
> Product Planning and Standards
> Nortel Networks
> Maidenhead Office Park,
> Westacott Way, Maidenhead,
> Berks SL6 3QH, UK
> email: [EMAIL PROTECTED]
> Tel: +44 (0)1628 432719
> ESN: 560-2719
>
> _______________________________________________
> 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
