Subject: RE: [SIP] From tags (was: I-D ACTION:draft-ietf-sip-service-examp les-00.txt)

From: [email-masked]
Date: Wed, 22 Nov 2000 09:52:53 -0600

Why don't you have two fixed and permanent tags: a "from" tag and a "to"
tag? Won't that solve the problems with calling yourself?

I think you're taking the text in rfc-bis too literally: it is really
recommending that the UA be able to recognize its own tags across reboots.
Having two tags instead of one doesn't interfere with the intention.

> -----Original Message-----
> From: EXT Billy Biggs [mailto:[email-masked]]
> Sent: Tuesday, November 21, 2000 10:40 PM
> To: Henning G. Schulzrinne
> Cc: Lars Berggren; Jo Hornsby; Alan Johnston; Henry Chen; SIP List
> Subject: Re: [SIP] From tags (was: I-D
> ACTION:draft-ietf-sip-service-examples-00.txt)
> 
> 
> Henning G. Schulzrinne ([email-masked]):
> 
> > I have yet to understand why re-using the same tag across restarts
> > hurts anything. After all, you're not worried about 
> confusing messages
> > when a SIP UA is revived.
> > 
> > Maybe we should look at the self-call in a bit more detail
> > [...]
> > The major problem occurs probably not so much because of 
> mapping, but
> > rather since this is treated as a re-INVITE while the first one is
> > still pending.
> 
>   Sorry I don't quite understand what you mean.  It looks like your
> email got a bit truncated.
> 
>   To help, I'm going to describe a scenario where a UA calls 
> itself, and
> that UA always uses a local tag (To or From) of 7.  Hopefully 
> this will
> help to clarify the problem.
> 
> 
>    I decide to call myself.  I create a call-leg struct to 
> represent it.
> Let's call it "Line 1".  I send out the initial INVITE:
> 
>   [From Line 1]
>   INVITE sip:me@proxy
>   Via: SIP/2.0/UDP my.ip
>   To: <sip:me@proxy>
>   From: <sip:me@proxy>;tag=7
>   Call-ID: 5
> 
>   This eventually loops back to me.  Now I see coming in:
> 
>   INVITE sip:me@proxy
>   Via: SIP/2.0/UDP some.ip
>   To: <sip:me@proxy>
>   From: <sip:me@proxy>;tag=7
>   Call-ID: 5
> 
>   I check and see there is no To-tag, so this is a new 
> incoming call.  I
> create a call struct to represent it, called "Line 2".  Line 2 now
> begins ringing.  I respond with a 180 and the user switches lines and
> answers the incoming call:
> 
>   [From Line 2]
>   SIP/2.0 200 OK
>   Via: SIP/2.0/UDP some.ip
>   To: <sip:me@proxy>;tag=7
>   From: <sip:me@proxy>;tag=7
>   Call-ID: 5
> 
>   When I receive this response, I find the related pending 
> transaction.
> Arguably, I could first find which call-leg it is destined to (and
> immediately have a problem), but say that I do transaction 
> mapping first
> so we don't break yet.  I match the OK and send an ACK:
> 
>   [From Line 1]
>   ACK sip:me@contactaddr
>   Via: SIP/2.0/UDP my.ip
>   To: <sip:me@proxy>;tag=7
>   From: <sip:me@proxy>;tag=7
>   Call-ID: 5
> 
>   At which point the other pending transaction also correctly matches
> this ACK to it.
> 
>   Now, on Line 2, I decide to hang up.  I've had enough of talking to
> myself.  So, I send a BYE:
> 
>   [From Line 2]
>   BYE sip:[email-masked]
>   Via: SIP/2.0/UDP my.ip
>   To: <sip:me@proxy>;tag=7
>   From: <sip:me@proxy>;tag=7
>   Call-ID: 5
> 
>   I now see this incoming BYE:
> 
>   BYE sip:[email-masked]
>   Via: SIP/2.0/UDP some.ip
>   To: <sip:me@proxy>;tag=7
>   From: <sip:me@proxy>;tag=7
>   Call-ID: 5
> 
>   Which one of the calls is it for?  Is it for the line which 
> originated
> the call, or the line which received the call?
> 
>   Using unique tags per call avoids any confusion even in 
> this case, and
> also protects the UA against clients which always use the same tag and
> happen to make two calls with the same Call-ID.
> 
> -- 
> Billy Biggs, 3Com               Email: [email-masked]
> http://www.div8.net/billy/      Phone: [email-masked]
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Billy Biggs <[email-masked]>
Date: Wed, 22 Nov 2000 10:34:07 -0600

[email-masked] ([email-masked]):

> Why don't you have two fixed and permanent tags: a "from" tag and a
> "to" tag?  Won't that solve the problems with calling yourself?
> 
> recommending that the UA be able to recognize its own tags across
> reboots.  Having two tags instead of one doesn't interfere with the
> intention.

  Building a crash-proof UA is not as simple as bis makes it out to be.
Rather than putting little hints throughout bis, there should be a
separate document describing methods and their problems.

  My point was that the recommendation will lead to broken behavior.

  To start this seperate document, here is a list of requirements for
Crash-proofness without saving call-state for all active calls:

  1. The ability to identify a tag as having originated from the
     pre-crash UA which this new UA is subsuming.  A better idea is to
     have the tag in two parts, one which is a hash of something unique
     to the UA, the other something random.  These tags MUST be unique
     to the instance.

  2. The ability to choose increasing cseq numbers across reboots and
     across calls.  Just trying to work through what's needed here is
     very difficult.  If you want to keep cseqs monotonotically
     increasing in each active call, then your cseq must be based on a
     hash of the call-leg information!  Ouch!

  3. Some security mechanism such that attacking UAs can't suddenly
     appear on your phone as if you were already in a call without the
     phone ringing!

  4. Some scheme whereby the remote end knows to send a re-INVITE to
     kickstart the call.  I have doubts about the following scenario:

     Say that Bob is on the phone to Jill:
     Bob: "blah blah... Jill?  Jill are you there?"

     Bob suddenly realizes that Jill isn't there!  Does Bob:

     a) Hang up the call and call Jill back
  or b) Put Jill on hold, and then take Jill off hold, with hopes the
        phone at the other end has just crashed.

     I find (b) to be far less likely.

  Because of the complexity, this should not be discussed in bis.