El Wednesday 13 August 2008 10:58:24 Victor Pascual Ávila escribió: > Hi Iñaki, > > On Mon, Aug 11, 2008 at 4:35 PM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote: > > Hi, RFC 4916 just handles "From" header, but what about if the initial > > request or in-dialog re-INVITE/UPDATE (RFC 4916) contains a > > P-Asserted-Identity header? > > > > For example, if a B2BUA sends INVITE to phone A like: > > > > INVITE sip:[EMAIL PROTECTED] > > From: sip:[EMAIL PROTECTED] > > To: sip:[EMAIL PROTECTED] > > P-Asserted-Identity: tel:+1234 > > Supported: from-change > > > > then phone A should render "1234" as callerid (if it supports it of > > course). Imagine B2BUA sends now an UPDATE like: > > > > UPDATE sip:[EMAIL PROTECTED] > > From: sip:[EMAIL PROTECTED] <-- CHANGED > > To: sip:[EMAIL PROTECTED] > > (no P-Asserted-Identity header) > > > > Should then phone A render "sip:[EMAIL PROTECTED]" as callerid? or still > > "tel: > > +1234"? > > And what about if the UPDATE contains again "P-Asserted-Identity: > > tel:+1234"? > > > > IMHO the normal behaviour is that original "P-Asserted-Identity" should > > remain rendered but it makes impossible to update the callerid if needed. > > I think you are rising a good point. IMO, the identity should be > updated using the one specified in the UPDATE's From, when PAI is not > there.
So you think that it PAI remains in the UPDATE (with different From) then the callerID should remain being the PAI. But note also that PAI cannot be update (there is not pai-change extension). So? -- Iñaki Baz Castillo [EMAIL PROTECTED] _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
