RE: [Sip] SIP Identity using Media Path

["Christer Holmberg (JO/LMF)" <christer.holmberg@xxxxxxxxxxxx>]

Hi Dan,

I was planning to provide an example myself, but you seem to have done
the work for me :)

>>>>>The CSeq (at least the digit portion) may also be modified, for
example if there has been some "dialog piggybacked" 
>>>>>requests sent between the SBC and another entity, but not
end-to-end. In that case the the SBC may have to increase the CSeq
before 
>>>>>forwarding the request, if the digit portion value has already been
used in a request sent by the SBC in the same direction.
>>>>
>>>>That seems like a good opportunity, within that trust domain 
>>>>between the SBC and the other entity, to use P-Asserted-Identity.
>>> 
>>>I am not sure I understand. How could the P-A-I header be used
instead of the CSeq?
>> 
>>The SBC that wants to interfere with the CSeq when doing 'dialog 
>>piggybacking' can go ahead and do that.  Doing that will destroy the 
>>validity of the SIP-Identity-Media signature for the 'dialog 
>>piggybacked' request.  Because the SBC and the 'other entity'
>>(which is receiving the 'dialog piggybacked' message) are both in the 
>>same trust domain, they can use P-A-I between themselves.
> 
>I sketched out what you had said, and I now understand what 
>you were saying.  The case is like this:
> 
>               +----+
>               |    +------CSeq=2--(dialog piggybacked request-->
>   -CSeq=1---->+ SBC|
>               |    +------CSeq=1--(request)-->
>               +----+
> 
>What I had suggested was that the piggybacked request (the 
>one with CSeq=2) could be sent with P-A-I (created by the 
>SBC), as it was being sent to another entity within the same 
>trust domain as the SBC.
> 
>The difficulty you were describing was that when the next 
>request arrives, it may be using CSeq=2:
> 
>               +----+
>               |    +-->
>   -CSeq=2---->+ SBC|
>               |    +-->
>               +----+
> 
>the SBC would need to disambiguate the newly-arrived CSeq 
>from the piggybacked (spoofed) request the SBC created from 
>the previous request.

Yes. The SBC would need for forward the request with an increased CSeq
value, e.g. Cseq=3.

Having said that, I think it's quite unlikely that the SBC would
piggyback anything before it receives the initial INVITE, so for that
request it is maybe possible to assume that the CSeq will stay
unchanged.

But, during the dialog the SBC may have to change the Cseq digit value,
and I've also seen use-cases where the method is changed.

Regards,

Christer