Jeroen van Bemmel wrote:
> Hi Sourabh,
>
> I would say "no" - should not use UPDATE in this way. I don't see why you
> would want to - isn't B's GRUU used as the request URI in your scenario, and
> not in any Contact header?
>
> gruu-10 states that 'A request sent to a GRUU SHOULD NOT be redirected',
> since it might break NAT traversal. The best option for "The network" IMO
> would be to simply treat the request as if it had been sent to B's AoR, and
> do the sequential ringing forking thing.
You do neither the caller nor the callee a favor when you ignore the
wishes of the caller. If the caller only wished to talk to a particular
UAS, and you don't wish to allow that, then simply fail the call.
Otherwise you are 2nd guessing *why* the caller used the gruu. That is
not a bet you can win reliably.
Paul
> Regards,
>
> Jeroen
>
> ----- Original Message -----
> From: "SOURABH ANPAT" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Wednesday, September 20, 2006 6:32 PM
> Subject: [Sip-implementors] GRUU related UPDATE method
>
>
>> 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. 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, 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.
>>
>> 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, 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. Party A may then
>> re-initiate (using SIP UPDATE) communication with party B by not
>> including party B GRUU.
>> * Is it possible to use UPDATE in such a manner to change the
>> Contact header within the Invite dialog?
>>
>>
>> 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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
