Subject: 481 response to an unknown tag

From: Robert Sparks <[email-masked]>
Date: Thu, 10 Feb 2000 09:42:10 -0600

I want to call implementers attention situations like this. User agent A
receives the following message having no previous knowledge of the contained
Call-ID, To, or From.

                             Agent
                               A
    INVITE A@there             |
    To: A@there;tag=abcd       |
    From: B@here               |
    Call-ID: 42@here           |
    -------------------------->|

A MUST respond to this with a 481 Call Leg/Transaction Does Not Exist.

A MUST NOT create a new call leg using the given tag (or multiple endpoints
of a forked request will end up sharing a tag, defeating its purpose).
Implementers should also take care not to blindly append a tag to the To:
line when receiving a request for an unknown Call-ID (rendering something
like To: A@there;tag=abcd;tag=1234 in the response).

I propose this clarification to the last paragraph of section 10.1.1:

"If the Call-ID was not found, the To: field is inspected for a tag
parameter. The server rejects the request if a tag is present. Otherwise,
a new call leg is created, with entries for the To, From and Call-ID
headers. The server returns a response containing the same To value, but
with a unique tag added. The tag MAY be omitted if the request contained
only one Via header field."

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 10 Feb 2000 14:08:01 -0500

I've updated the draft accordingly, with minor editorial changes.
Thanks.

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

---

From: Jeff Gao <[email-masked]>
Date: Thu, 10 Feb 2000 11:34:51 -0800

I have two questions with regard to the propsed INFO message.  Let's say A and B
are two UAs.

1.  A calls B
2.  A sends B an Info message. Its callleg looks like the following:

        From: A
        To: B
        Call-ID: xxxxxx
3.   B receives the info message, compares the callleg with existing callleg and
accepts the info message

4.  B then sends A an info message that looks like the following:

        From: B
        To: A
        Call-ID: xxxxxx

5. A receives the message and compares the callleg.  The existing callleg known
to A has the To and From field fliped from the To and From field in the info
message A received from B.  In this case, the INFO message spec requires A to
reject B's info message with a "481 Call Leg/Transaction Does Not Exit" response.

My questions are:

a.  is my interpretation of the INFO message spec correct?
b.  If my interpretation is correct, then how do I send INFO message from B to A?

Thanks in advance for any help.

Best Regards,

Jeff Gao

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 10 Feb 2000 14:20:45 -0600 (CST)

>reject B's info message with a "481 Call Leg/Transaction Does Not Exit" 

This has been hashed over *many* times on the list:
A call leg is identified by the tuple of (Call-ID, Remote-URI, Local-URI).

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Feb 2000 17:17:03 -0500

> only one Via header field."

Actually, I'd prefer to drop this last sentence. I hate special cases
like this. I'd much rather write my client not having to consider that a
tag might not appear.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com