Subject: RE: [Sip] The logic behind the From tag?

From: "Rob Phillips" <[email-masked]>
Date: Tue, 14 Jun 2005 07:34:41 -0500

I'm not saying the Call-Id can't be trusted to be unique, although it's certainly possible (although unlikely) that it might not be unique.  I'm saying, having the From and To tag both help determine direction of a call and provide additional guarantees to the uniqueness of the call.

Let me give you another thought:

-Caller-     -Proxy-      -Callee-
INVITE ------------------>
CallId=x
From-Tag=
To-Tag=
       <----------------- 200 OK
                          CallId=x
                          From-Tag=
                          To-Tag=y
ACK    ------------------>
CallId=x
From-Tag=
To-Tag=y
       <----------------- INVITE
                          CallId=x
                          From-Tag=
                          To-Tag=

Now the initial INVITE from the caller and the reINVITE from the callee look the same.  Suppose your proxy was a parallel forking B2BUA proxy who sent the INVITE in several different directions.  You got the 200 OK from the callee and ACK from the caller, but it may be that at some point after that, one of those other forks comes back though you again (on it's way to a destination on the other side of you).  Now how can you tell the difference between that forked INVITE and a reINVITE from the callee?  You can't, so you have to allow it through.  If, however, you had both a known To and From tag, and then you get an INVITE that just has a From tag, you instantly know it's not allowed and can return an error accordingly.

In the end, what does sending a From tag hurt, anyway?  After this flow completes, you would get:

200 OK ------------------>
CallId=x
From-Tag=
To-Tag=z
       <----------------- ACK
                          CallId=x
                          From-Tag=
                          To-Tag=z

anyway, and doesn't that just end up specifying a From and To tag?  But by specifying the From and To tag up front, it's easier to follow the flow from the beginning (in terms of INVITE vs. re-INVITE and caller vs. callee).

- rob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Frank Derks
Sent: Tuesday, June 14, 2005 6:20 AM
To: Rob Phillips
Cc: [email-masked]
Subject: RE: [Sip] The logic behind the From tag?

Hi Rob,

The fact that the callee uses the same Call-ID is sufficient information to 
have the caller decide that this is a request on the same call. If you are
inferring that the Call-ID, although it is supposed to be unique, does not
provide this information, it is equally true that the From tag does not
provide this either. 

However, I do see a point. The fact that a From tag is present, does provide
an indication that this is a request on an exisisting dialog. It does, however,
raise the issue about the uniqueness of the To tag, the From tag and the 
Call-ID.

What you're saying is that the Call-ID cannot be trusted to be unique and that
another, again probably not so unique, parameter is added to determine whether 
or not a request belongs to an existing dialog.

Cheers,

Frank

"Rob Phillips" 
2005-06-14 12:02 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
<[email-masked]>
cc

Subject
RE: [Sip] The logic behind the From tag?
Classification

Actually, I'd say the From tag is there to determine the direction of a 
call and it's validity.

Consider if you had no From tag: you send out an initial INVITE with no 
>From and no To tag but with a unique call-ID.  No problem so far.  The 
callee receives the call and inserts it's To tag in the response.  Again, 
no problem.

Now the callee wants to put the call on hold.  OK, so it now swaps From 
and To to generate the request (so you can tell it's generated from the 
callee and not the caller)...but there's no From tag.  The call-ID is the 
same, but it looks like a new request: no From tag, no To tag.

The original caller gets this request and ... what is he supposed to do 
with it?  Is it a re-INVITE?  A separate call?  What if was a non-INVITE 
request?  You don't know how to handle it because you don't have the 
To/From tag combination to tell you what is going on.

- rob

--
Rob Phillips, Sr. Software Engineer                 Netrake Corporation
mailto: [email-masked]                           3000 Technology Drive
voice: (214) 291-1096                                         Suite 100
fax:   (214) 291-1010     http://www.netrake.com     Plano, Texas 75074

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Frank Derks <[email-masked]>
Date: Tue, 14 Jun 2005 20:40:58 +0200

Rob,

Since the second INVITE does not contain any tags, it does not have the 
same dialog ID as the already existing dialog! The first dialog has a 
dialog ID that consists of an empty From tag, a Call-ID with the value x 
and a To tag with the value y. The second invite will, at the worst, have 
an identical Call-ID and empty From and To tags. So there's no match.

I agree that including a From tag doesn't hurt a bit and we could argue 
about it being an "elegant" to do the same thing for both directions. 
However,I am just trying to understand why it would be necessary, because 
the RFC does not give an explanation for this tag (it does have one for 
the To tag).

Am I missing something in your example?

Cheers,

Frank

"Rob Phillips" 
2005-06-14 02:34 PM

To

I'm not saying the Call-Id can't be trusted to be unique, although it's 
certainly possible (although unlikely) that it might not be unique.  I'm 
saying, having the From and To tag both help determine direction of a call 
and provide additional guarantees to the uniqueness of the call.

Now the initial INVITE from the caller and the reINVITE from the callee 
look the same.  Suppose your proxy was a parallel forking B2BUA proxy who 
sent the INVITE in several different directions.  You got the 200 OK from 
the callee and ACK from the caller, but it may be that at some point after 
that, one of those other forks comes back though you again (on it's way to 
a destination on the other side of you).  Now how can you tell the 
difference between that forked INVITE and a reINVITE from the callee?  You 
can't, so you have to allow it through.  If, however, you had both a known 
To and From tag, and then you get an INVITE that just has a From tag, you 
instantly know it's not allowed and can return an error accordingly.

In the end, what does sending a From tag hurt, anyway?  After this flow 
completes, you would get:

anyway, and doesn't that just end up specifying a From and To tag?  But by 
specifying the From and To tag up front, it's easier to follow the flow 
from the beginning (in terms of INVITE vs. re-INVITE and caller vs. 
callee).

- rob

-----Original Message-----

Hi Rob,

The fact that the callee uses the same Call-ID is sufficient information 
to 
have the caller decide that this is a request on the same call. If you are
inferring that the Call-ID, although it is supposed to be unique, does not
provide this information, it is equally true that the From tag does not
provide this either. 

However, I do see a point. The fact that a From tag is present, does 
provide
an indication that this is a request on an exisisting dialog. It does, 
however,
raise the issue about the uniqueness of the To tag, the From tag and the 
Call-ID.

What you're saying is that the Call-ID cannot be trusted to be unique and 
that
another, again probably not so unique, parameter is added to determine 
whether 
or not a request belongs to an existing dialog.

Cheers,

Frank

"Rob Phillips" 
2005-06-14 12:02 PM

To

Subject

- rob