Subject: [SIP] I-D ACTION:draft-ietf-sip-service-examples-00.txt

From: [email-masked]
Date: Mon, 20 Nov 2000 06:17:40 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: SIP Telephony Service Examples
	Author(s)	: A. Johnston, R. Sparks, C. Cunningham, 
                          S. Donovan, K. Summers
	Filename	: draft-ietf-sip-service-examples-00.txt
	Pages		: 90
	Date		: 17-Nov-00
	
This document gives examples of SIP (Session Initiation Protocol)
telephony services.  This covers most features offered in so-called
Centrex offerings from local exchange carriers and PBX (Private
Branch Exchange) features.  Most of the services shown in this
document are implemented in the SIP User Agents, although some
require the assistance of a SIP Proxy.  Some require some extensions
to SIP including third party call control (3pcc) extensions such as
the REFER method. These features are not intented to be an exhaustive
set, but rather show implementations of common features likely to be
implemented on SIP IP Telephones in a business environment.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-service-examples-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-service-examples-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-service-examples-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Henry Chen <[email-masked]>
Date: Mon, 20 Nov 2000 17:32:38 -0600

Hi:

    There are some inconsistencies for To Tag in the call flows.

    In 2.3 Consultation Hold:

   The To Tag "tag=314159"  in  F4 180 Ringing B -> Proxy 1
    is copied to the From header in the F10 Invite  request.

    But in 2.4 Unattended Transfer:

    The To Tag " tag=314159"  in F3 ACK B -> A
    is copied to the To header in the F4 Invite request.

    According to RFC2543bis, 2.3 Consultation Hold is correct.
    Please confirm.

    Thanks,

    Henry

      2.3 Consultation Hold
      ...

   /* User B places User A on hold. */

   F10 INVITE B -> Proxy 1

   INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/UDP there.com:5060
   Route: <sip:[email-masked]>
   From: LittleGuy <sip:[email-masked]>;tag=314159
   To: BigGuy <sip:[email-masked]>
   Call-ID: [email-masked]
   CSeq: 1 INVITE
   Contact: LittleGuy <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: ...

    The To Tag "tag=314159"  in  F4 180 Ringing B -> Proxy 1
    is copied to From header in the F10 Invite  request.

    2.4 Unattended Transfer

     /* Session is established between A and B.  User B then places User A
   on hold */

   F4 INVITE A -> B

   INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/UDP there.com:5060
   From: BigGuy <sip:[email-masked]>
   To: LittleGuy <sip:[email-masked]>;tag=314159
   Call-ID: [email-masked]
   CSeq: 1 INVITE
   Contact: BigGuy <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: ...

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

---

From: Billy Biggs <[email-masked]>
Date: Mon, 20 Nov 2000 20:14:12 -0600

>  There are some inconsistencies for To Tag in the call flows.

  The example that Henry points out is of course a bug.

  Without having read the draft in depth, I would also like to request
to the authors that From tags be inserted everywhere.  From tags (on
initial requests) are important for call-leg matching in the presence of
forking proxies, which pretty much means everywhere.  I don't want to
encourage people not to use them.

  As well, it would be nice to see random tags per call.  You have UserB
always using the same tag.  As I've mentioned before on this list, this
is dangerous and a bad idea.

-- 
Billy Biggs, 3Com               Email: [email-masked]
http://www.div8.net/billy/      Phone: [email-masked]

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 20 Nov 2000 21:19:24 -0500

> is dangerous and a bad idea.

Note that not everybody agrees with this. This is a trade-off between
features. Different people come to different conclusions as to what the
right trade-off is.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Billy Biggs <[email-masked]>
Date: Mon, 20 Nov 2000 20:44:19 -0600

Henning G. Schulzrinne ([email-masked]):

> >   As well, it would be nice to see random tags per call.  You have
> > UserB always using the same tag.  As I've mentioned before on this
> > list, this is dangerous and a bad idea.
> 
> features. Different people come to different conclusions as to what
> the right trade-off is.

  Sorry, I didn't realize this was a contended issue.

  Right now the text reads, "[...] but it is RECOMMENDED to maintain the
same tag across calls and instances of the UA to allow restarting of a
user agent."

  If that is to be kept, then please also mention that UAs which exhibit
this behavior be able to tell when a request loops back to themselves.
This can happen in many cases, and I've seen UAs crash because they
can't perform call-leg matching.

  Some cases:

  1. User makes a call through a proxy which forks back to themselves (I
     called Joe but Joe has his calls forwarded to me).

  2. User sends a SUBSCRIBE for their voicemail to sip:me@myproxy with
     an Accept-Contact: *;feature="voicemail", but the user doesn't have
     a voicemail server so the SUBSCRIBE comes back to the phone.

  3. User calls themselves through their own proxy to make sure their
     registration is active.

  I mean, sure, UAs can have the logic inside them to detect this case,
but in bis the suggestion is to always use the same tag without mention
of them.  You should also mention that soft-phones should avoid choosing
a tag based on the MAC address.

  I think the how-to-create-a-crash-proof-SIP-UA stuff should be in a
seperate document, not in the SIP RFC.  It's more complicated than just
choosing the same tag.  You have to realize that Routes won't be kept,
hope the far end sends a re-INVITE, etc...  IMHO, recommending that UAs
choose the same tag is asking for trouble.  Does noone else agree?

---

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 21 Nov 2000 12:24:17 -0000

>      a voicemail server so the SUBSCRIBE comes back to the phone.

Am I right in thinking that both of these cases are reasonably
easily solved if the UA always inserts a From tag, too; or is
the problem more subtle than that?

Cheers,

 - Jo.

---

From: Billy Biggs <[email-masked]>
Date: Tue, 21 Nov 2000 08:13:12 -0600

Jo Hornsby ([email-masked]):

> Billy Biggs wrote:
> >   If that is to be kept, then please also mention that UAs which
> > exhibit this behavior be able to tell when a request loops back to
> > themselves.  This can happen in many cases, and I've seen UAs
> > crash because they can't perform call-leg matching.
> > 
> >   Some cases:
> > 
> >   1. User makes a call through a proxy which forks back to
> >      themselves (I called Joe but Joe has his calls forwarded to
> >      me).
> > 
> >   2. User sends a SUBSCRIBE for their voicemail to sip:me@myproxy
> >      with an Accept-Contact: *;feature="voicemail", but the user
> >      doesn't have a voicemail server so the SUBSCRIBE comes back to
> >      the phone.
> 
> Am I right in thinking that both of these cases are reasonably easily
> solved if the UA always inserts a From tag, too; or is the problem
> more subtle than that?

  Their suggestion was that the UA always use the same local tag so when
you're rebooted and see a re-INVITE you know not to return a 481 cause
it's actually for you.  It's in bis-02.  For that to work, the UA will
always put in a from tag on outgoing requests, but it will always be the
same.  As well, the UA will always answer with the same to tag on
outgoing responses.

  So, UA sends a request, it loops back, they end up putting the same
tag as the To and as the From...  You see the problem?  Call-leg
endpoint matching is based on:

  call-id,local-uri,local-tag,remote-uri,remote-tag

  And you'll end up with the same key for both.  The code gets cleaner
if you always pick random tags.  Unfortunately, call-leg-end matching is
very difficult.

  As an aside, things would be alot more robust if tags were mandatory.
Ideally, I want to match on:

  call-id,local-tag,remote-tag

  (or for an unconnected call-leg end):

  call-id,local-tag

  Much nicer than this total hack of trying to compare the URIs,
especially when they aren't SIP URIs.  Oh well.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 21 Nov 2000 11:17:14 -0500

> if you always pick random tags.  Unfortunately, call-leg-end matching is

I'm not sure I follow this logic. If A calls B and B proxies back to A,
we get A sending

INVITE B
From: A
To: B

The proxy forwards it to A again:

INVITE A
From: A
To: B

A can easily tell that it was the origin of the request ("From: A"), so
I'm not sure how tags get involved here. In this example, the request
doesn't even have To tags.

> especially when they aren't SIP URIs.  Oh well.

I doubt that anything but tel: URLs will be useful in this context, so
I'm not sure how big a problem this is. I assume by "local-tag" you mean
the From tag?
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Billy Biggs <[email-masked]>
Date: Tue, 21 Nov 2000 11:26:00 -0600

Henning G. Schulzrinne ([email-masked]):

> >   So, UA sends a request, it loops back, they end up putting the
> > same tag as the To and as the From...  You see the problem?
> > Call-leg endpoint matching is based on:
> > 
> >   And you'll end up with the same key for both.  The code gets
> > cleaner if you always pick random tags.  Unfortunately,
> > call-leg-end matching is very difficult.
> 
> I'm not sure I follow this logic. If A calls B and B proxies back to
> A, we get A sending
> 
> INVITE B
> From: A
> To: B
> 
> A can easily tell that it was the origin of the request ("From: A"),
> so I'm not sure how tags get involved here. In this example, the
> request doesn't even have To tags.

  What if A and B are the same URI?  How do I tell them apart?  The user
answers the call, I send a 200 OK to the INVITE and then ACK it.  Now
one of the lines hangs up and I send a BYE: how can I tell which
call-leg end the BYE was meant for when it comes back?  Was I even able
to match that ACK properly?  Do I have to special-case calls to myself?
That would be really annoying, especially if I'm a gateway.

  Also note that if you have two UAs which always use the same tags, and
there are two calls up between them, you're relying on the call-id for
each call to be unique in order to tell them apart.  I'm not convinced
this will always be the case, as there have been hints that the call-id
can be reused to infer special behavior (see my Replaces draft for a
cleaner solution).

> [...] I assume by "local-tag" you mean the From tag?

  Well, when I send a request I put the localuri/localtag as the from
and the remoteuri/remotetag as the to.  When I receive an initial
request, I populate the localuri from the to and add a localtag, and the
remoteuri/remotetag is taken from the from.

  I don't like calling them 'To tags' or 'From tags' because it gets
confusing.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 21 Nov 2000 12:39:13 -0500

Billy Biggs wrote:

>   What if A and B are the same URI?  How do I tell them apart? 

Are you saying that A wants to talk to himself? How else would they be
the same under normal circumstances? A gateway may want to connect two
ports on the same box through the network, but they would have different
phone numbers, i.e., different From/To/Request-URIs.

I also don't see that if you do normal loop detection, you couldn't
handle calls to yourself. Responses and ACKs go to the Via or Contact,
respectively.

Again, given that in this scenario, tags aren't even involved, I'm at a
loss as to why they can matter.

>  The user

Calls to myself are probably a case for the psychologist or a support
group :-)

> can be reused to infer special behavior (see my Replaces draft for a

If anything, we're probably moving away from overloading the call-id,
primarily because you can't control it when somebody "calls in".

>   I don't like calling them 'To tags' or 'From tags' because it gets

I find the designation local/remote tags confusing...

---

From: Billy Biggs <[email-masked]>
Date: Tue, 21 Nov 2000 12:02:41 -0600

Henning G. Schulzrinne ([email-masked]):

> ports on the same box through the network, but they would have
> different phone numbers, i.e., different From/To/Request-URIs.

  Yes, A wants to talk to himself.  This is a perfectly reasonable
diagnostic to see if my registration is active.  We do it routinely
here.  I don't see why it is acceptable to have it fail.

  I mean, you can telnet to yourself, right?

  What happens when you SUBSCRIBE to your own presence information so
you can watch how you appear online?  Those NOTIFYs have to map
correctly somewhere.

> handle calls to yourself. Responses and ACKs go to the Via or Contact,

  Well, UAs don't forward requests and therefore don't do loop
detection.  Sure you might properly handle responses to the single
request, but the rest of the requests in that call will fail.

> primarily because you can't control it when somebody "calls in".

  Great.  I'd also love to hear what you think of Replaces.
  http://www.sip-happens.com/replaces/

> >   Well, when I send a request I put the localuri/localtag as the
> > from and the remoteuri/remotetag as the to.  When I receive an
> > initial request, I populate the localuri from the to and add a
> > localtag, and the remoteuri/remotetag is taken from the from.
> > 

  From an implementation point of view it isn't.  When you receive a SIP
message, you need to first match it to see if its related to any
currently active call leg ends.  At this point we don't care if its a
request or response, so To/From becomes ambiguous.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 21 Nov 2000 21:47:55 -0500

Lars Berggren wrote:

> 
> I agree with Billy and would suggest that tags should be unique to each
> instance of a user agent and maybe even unique to a call.

They are already unique to each instance of a user agent, as described.
If you have two SIP UAs running on the same host (on different ports,
presumably), they will have different tags. The same "brand" of UA on
different hosts will have different UAs. If it were useful, having
different tags for From and To from the same UA may even be useful,
although it would be nice to have a scenario for that.

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 (I'm assuming
From tags here):

INVITE self
To: self
From: self;tag=T
Via: self

This will be "filed" under to=self/*, from=self/T. Any incoming request
will have their From/To reversed and mapped. As long as the two tags

The response will be

200 OK
To: self;tag=T
From: self;tag=T

This will map to the same entry. A BYE will then use

BYE self
To: self;tag=T
From: self;tag=T

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.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Billy Biggs <[email-masked]>
Date: Tue, 21 Nov 2000 21:40:09 -0600

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
> [...]
> 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.

---

From: Lars Berggren <[email-masked]>
Date: Wed, 22 Nov 2000 01:48:01 +0100 (CET)

> That would be really annoying, especially if I'm a gateway.

At a first look I think this is solved by the following phrase in
section 6.25 in rfc2543:

   The "tag" MAY appear in the From field of a request. It MUST be present
   when it is possible that two instances of a user sharing a SIP address
   can make call invitations with the same Call-ID.

This seems to imply that the tags should be different to be useful.

However, as Billy mentioned, a piece of new text is added which says:

   A single user agent maintains the same tag at least within the same
   Call-ID, but it is RECOMMENDED to maintain the same tag across calls
   and instances of the UA application to allow restarting of a user
   agent.

Since tags primarily are used for differentiating of multiple instances of
a SIP address, I think having the same tag across instances of the UA
might break the protocol more than it helps. And, why does the UA
crash anyway? Well, maybe because identical tags across UAs creates shaky
scenarios as the one described earlier in this thread. And if the tags are
unique to each UA, the UA may be less likely to have to reboot in the
first place.

/Lars

Lars Berggren       <mailto:[email-masked]>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 24 Nov 2000 10:27:31 -0500

I'm not sure, but it seems that there's a simple fix: simply have the UA
create *different* tags depending on whether this is for a From or To.
However, the tag is constant across calls and requests.

The general matching rule is

- match incoming requests so that the To matches the locally generated
tag and
  the From matches the tag generated by the other side

Modifying the running example to use tag=5 for the To tag

>   To: <sip:me@proxy>;tag=5

Modification here.

>   To: <sip:me@proxy>;tag=5

As usual, the callee simply flips To and From.

>   [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=5
>   Call-ID: 5
> 
>   From: <sip:me@proxy>;tag=5
>   Call-ID: 5
> 

Using the rule above, it matches the call on line 1, since 7 is the
locally-generated tag (stuck into From).

> happen to make two calls with the same Call-ID.

Since both Line1 and Line2 have the same call-ID (one incoming and one
outgoing), they would have the same locally generated tag according to
your rule, so I don't see how this helps.

Two calls with the same call-id can't happen, by definition. If they do,
the implementation is broken (and would presumably generate the "wrong"
tag, too, while it is at it).

---

From: Billy Biggs <[email-masked]>
Date: Mon, 27 Nov 2000 00:05:08 -0600

Henning G. Schulzrinne ([email-masked]):

> I'm not sure, but it seems that there's a simple fix: simply have the
> UA create *different* tags depending on whether this is for a From or
> To.  However, the tag is constant across calls and requests.

  Even safer to use "predictable-random", however:

  Choosing predictable tags does not make a UA crash-proof.  The SIP
spec should not recommend any behavior on generating tags.