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

["Bala Neelakantan" <[e-mail]>]

Drage,

Yes, I agree that draft should not be referred.  Sorry.  But the
original poster was asking about the reason behind it.  I searched the
SIP mailing list for reference and came across the reference.  The
reference for the logic behind the "from" tag has been removed from the
later drats and RFC.  Also I remember some explanation given about from
Tag in the rfc2543bis.

Thanks,
Neel


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Drage, Keith (Keith)
Sent: Wednesday, June 15, 2005 9:10 AM
To: 'Frank Derks'
Cc: [e-mail]
Subject: RE: [Sip] The logic behind the From tag?

Drafts normally expire and get removed from the i-d directory when an
RFC is approved.

Please refer to RFC 4028 if you wish to address thus discussion, and
given that session-timer reached -15 before being approved as this RFC,
it might me wise to ensure that the discussion point still applies after
such a large number of revisions.

regards

Keith

Keith Drage
Lucent Technologies
[e-mail]
tel: [phone]


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> Frank Derks
> Sent: 15 June 2005 12:31
> To: Rob Phillips
> Cc: [e-mail]
> Subject: RE: [Sip] The logic behind the From tag?
> 
> 
> Hi Rob,
> 
> I don't know if you saw the response from ""Bala 
> Neelakantan", who refers 
> to 
> the following expired draft RFC:
> 
> http://www.softarmor.com/wgdb/docs/draft-ietf-sip-session-timer-06.txt
> 
> Section 7.1 gives one possible reason why the From tag would 
> be required. 
> 
> In your new example I see two things that I do not quite understand:
> 
> 1) Why would the proxy send an INVITE with no To-tag on the 
> same Call-ID?
>    This suggests that some party "behind" the proxy happens 
> to have picked
>    an identical Call-ID to establish a call to the Caller.
> 2) Why doesn't the callee add the To-tag in the INVITE to the caller?
>    It was already clear that the To-tag makes sense, so I do 
> not see why
>    the callee adds it to the 200 OK, but doesn't add it to 
> the re-INVITE.
>    In your example it is not possible to distinguish between 
> the INVITE
>    from the Proxy and the Callee because the To-tag is left 
> empty. They
>    must be present and have unique and different values.
> 
> Cheers,
> 
> Frank
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> "Rob Phillips" 
> 2005-06-15 12:47 PM
> 
> To
> Frank Derks/HVS/BE/PHILIPS@PHILIPS
> cc
> <[e-mail]>
> Subject
> RE: [Sip] The logic behind the From tag?
> Classification
> 
> 
> 
> 
> 
> 
> 
> Apparently my description wasn't that clear.  Lemme draw it out:
> 
>              Parallel
>              Forking
> -Caller-     -Proxy-      -Callee-      -Proxy-
> INVITE --------->
> CallId=x
> From-Tag=
> To-Tag=
>              INVITE
>              CallId=x
>              From-Tag=
>              To-Tag=
>              ------------->
>              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=
>               <-------------------------- INVITE
>                                           CallId=x
>                                           From-Tag=
>                                           To-Tag=
> 
> Now how did you tell the difference between the INVITE from 
> the callee and 
> the INVITE from the proxy?  You can't.  You could, though, if you had 
> From-tags:
> 
>              Parallel
>              Forking
> -Caller-     -Proxy-      -Callee-      -Proxy-
> INVITE --------->
> CallId=x
> From-Tag=z
> To-Tag=
>              INVITE
>              CallId=x
>              From-Tag=z
>              To-Tag=
>              ------------->
>              INVITE
>              CallId=x
>              From-Tag=z
>              To-Tag
>              --------------------------->
> 
>        <----------------- 200 OK
>                           CallId=x
>                           From-Tag=z
>                           To-Tag=y
> ACK    ------------------>
> CallId=x
> From-Tag=z
> To-Tag=y
>               <---------- INVITE
>                           CallId=x
>                           From-Tag=y
>                           To-Tag=z
>               <-------------------------- INVITE
>                                           CallId=x
>                                           From-Tag=z
>                                           To-Tag=
> 
> - rob
> 
> -----Original Message-----
> From: Frank Derks [mailto:[e-mail]]
> Sent: Tuesday, June 14, 2005 1:41 PM
> To: Rob Phillips
> Cc: [e-mail]
> Subject: RE: [Sip] The logic behind the From tag?
> 
> 
> 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
> Frank Derks/HVS/BE/PHILIPS@PHILIPS
> cc
> <[e-mail]>
> Subject
> RE: [Sip] The logic behind the From tag?
> Classification
> 
> 
> 
> 
> 
> 
> 
> 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: [e-mail] [mailto:[e-mail]]On Behalf Of
> Frank Derks
> Sent: Tuesday, June 14, 2005 6:20 AM
> To: Rob Phillips
> Cc: [e-mail]
> 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
> <[e-mail]>
> 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: [e-mail]                           3000 
> Technology Drive
> voice: [phone]                                         
> Suite 100
> fax:   [phone]     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 [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip