Discussion:
[Sip-implementors] URI parameter in To and From headers
Biju Kayakal
2007-07-31 22:08:54 UTC
Permalink
Hi All,
A SIP endpoint receives a request containing the transport
param as URI parameter in the To header ?
E.g.
To: <sip:97775551000 at 45.60.51.41;transport=tcp>

Should it copy this URI parameter in the To header when it forms the
response ?
Also should it also copy this URI param into the From header when it has
to send subsequent requests within this dialog ?

RFC 3261 stats that when forming responses,
"If the To header field in the request did not contain a tag, the URI in
the To header field in the response MUST equal the URI in the To header
field"

And for subsequent transactions:
"The From URI of the request MUST be set to the local URI from the
dialog state"

How should the URI parameters be handled in this regard ?

Any inputs would be appreciated.

Thanks
-Biju
Singh, Indresh (SNL US)
2007-08-01 02:48:01 UTC
Permalink
The recommendation of RFC-3261 dialog layer w.r.t to localTargetURI at
UAS holds true here for response generation when a dialog is formed or
when requests are sent on an established dialogs. Once a response is
sent with a to-tag ( first provisonal 1xx response other than 100 trying
or first 2xx if no prov response is sent ) a dialog is created at the
UAS and at that point of time "localTargetUri" portion of dialog is
populated with information received in the incoming To header and
"localTag" is populated based on the generated tag at UAS.

Now on this dialog when a response is sent by the UAS it should copy
back the remoteTargetUri into To header and also append the localTag in
the to header. For subsequent requests in this dialog will copy the
remoteTargetUri into from header. Below are references from RFC-3261..

Please note that some requets can be non-dialog forming. In those cases
resposne will still be generated as per recommendation of Section
8.2.6.2.

Hopefully this helps answer your query.

Regards,

Indresh K Singh

8.2.6.2 Headers and Tags

..........

If a request contained a To tag in the request, the To header field
in the response MUST equal that of the request. However, if the To
header field in the request did not contain a tag, the URI in the To
header field in the response MUST equal the URI in the To header
field; additionally, the UAS MUST add a tag to the To header field in
the response (with the exception of the 100 (Trying) response, in
which a tag MAY be present). This serves to identify the UAS that is
responding, possibly resulting in a component of a dialog ID. The
same tag MUST be used for all responses to that request, both final
and provisional (again excepting the 100 (Trying)). Procedures for
the generation of tags are defined in Section 19.3.

12 Dialogs
.........

As one would expect for a UAS, the Call-ID value of the
dialog ID is set to the Call-ID of the message, the remote tag is set
to the tag in the From field of the message, and the local tag is set
to the tag in the To field of the message.


13.3.1.1 Progress

..........
These provisional responses establish early dialogs and therefore
follow the procedures
of Section 12.1.1 in addition to those of Section 8.2.6.

12.1.1 UAS behavior
.......
The remote URI MUST be set to the URI in the From field, and the
local URI MUST be set to the URI in the To field.

12.2 Requests within a Dialog
........

Once a dialog has been established between two UAs, either of them
MAY initiate new transactions as needed within the dialog. The UA
sending the request will take the UAC role for the transaction. The
UA receiving the request will take the UAS role.

12.2.1 UAC Behavior

12.2.1.1 Generating the Request

A request within a dialog is constructed by using many of the
components of the state stored as part of the dialog.

The URI in the To field of the request MUST be set to the remote URI
from the dialog state. The tag in the To header field of the request
MUST be set to the remote tag of the dialog ID. The From URI of the
request MUST be set to the local URI from the dialog state. The tag
in the From header field of the request MUST be set to the local tag
of the dialog ID.
........
-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu
[mailto:sip-implementors-bounces at lists.cs.columbia.edu] On
Behalf Of ext Biju Kayakal
Sent: Tuesday, July 31, 2007 6:09 PM
To: sip-implementors at lists.cs.columbia.edu
Subject: [Sip-implementors] URI parameter in To and From headers
Hi All,
A SIP endpoint receives a request containing the transport
param as URI parameter in the To header ?
E.g.
To: <sip:97775551000 at 45.60.51.41;transport=tcp>
Should it copy this URI parameter in the To header when it forms the
response ?
Also should it also copy this URI param into the From header
when it has
to send subsequent requests within this dialog ?
RFC 3261 stats that when forming responses,
"If the To header field in the request did not contain a tag,
the URI in
the To header field in the response MUST equal the URI in the
To header
field"
"The From URI of the request MUST be set to the local URI from the
dialog state"
How should the URI parameters be handled in this regard ?
Any inputs would be appreciated.
Thanks
-Biju
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Manjunath Warad
2007-08-01 05:38:32 UTC
Permalink
Hi Biju,
RFC recommends not to add transport param in From and To header.
However, if the end-point receives transport param then that param should be
ignored.

However about creation of responses, if the request is dialog
creating then
1. From header is clone as in request, drop all the unnecessary info like
transport param if any in request.
2. To header too is clone as in request, dropping all unnecessary info like
trans param and this end-point has to generate To tag.

Further mid-dialog request MUST carry the same From and To header in reverse
order with tags intact if generated from callee point.

If the request is not dialog creating one then To tag MUST NOT be generated.

For the information about the parameters in the URI you can look into Table
1 from RFC 3261.

Regards,
Manju


****************************************************************************
***********
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu
[mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of Biju
Kayakal
Sent: Wednesday, August 01, 2007 3:39 AM
To: sip-implementors at lists.cs.columbia.edu
Subject: [Sip-implementors] URI parameter in To and From headers

Hi All,
A SIP endpoint receives a request containing the transport param
as URI parameter in the To header ?
E.g.
To: <sip:97775551000 at 45.60.51.41;transport=tcp>

Should it copy this URI parameter in the To header when it forms the
response ?
Also should it also copy this URI param into the From header when it has to
send subsequent requests within this dialog ?

RFC 3261 stats that when forming responses, "If the To header field in the
request did not contain a tag, the URI in the To header field in the
response MUST equal the URI in the To header field"

And for subsequent transactions:
"The From URI of the request MUST be set to the local URI from the dialog
state"

How should the URI parameters be handled in this regard ?

Any inputs would be appreciated.

Thanks
-Biju
Singh, Indresh (SNL US)
2007-08-01 13:29:42 UTC
Permalink
Manju is correct that transport parameter should not be present in the
from and to header as per table-1 of RFC-3261.

Page 151 also suggest that Elements processing URI should ignore any
disallowed components if they are present.

But I am not sure if the transport parameter in the from header ( which
is not allowed ) should be ignored while populating the local target uri
information in dialog.

Paul could you kindly comment on this ??

Regards,

Indresh K Singh
-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu
[mailto:sip-implementors-bounces at lists.cs.columbia.edu] On
Behalf Of ext Manjunath Warad
Sent: Wednesday, August 01, 2007 1:39 AM
To: 'Biju Kayakal'; sip-implementors at lists.cs.columbia.edu
Subject: Re: [Sip-implementors] URI parameter in To and From headers
Hi Biju,
RFC recommends not to add transport param in From and To header.
However, if the end-point receives transport param then that
param should be
ignored.
However about creation of responses, if the request is dialog
creating then
1. From header is clone as in request, drop all the
unnecessary info like
transport param if any in request.
2. To header too is clone as in request, dropping all
unnecessary info like
trans param and this end-point has to generate To tag.
Further mid-dialog request MUST carry the same From and To
header in reverse
order with tags intact if generated from callee point.
If the request is not dialog creating one then To tag MUST
NOT be generated.
For the information about the parameters in the URI you can
look into Table
1 from RFC 3261.
Regards,
Manju
**************************************************************
**************
***********
This e-mail and attachments contain confidential information
from HUAWEI,
which is intended only for the person or entity whose address
is listed
above. Any use of the information contained herein in any way
(including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please
notify the sender by
phone or email immediately and delete it!
-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu
[mailto:sip-implementors-bounces at lists.cs.columbia.edu] On
Behalf Of Biju
Kayakal
Sent: Wednesday, August 01, 2007 3:39 AM
To: sip-implementors at lists.cs.columbia.edu
Subject: [Sip-implementors] URI parameter in To and From headers
Hi All,
A SIP endpoint receives a request containing the
transport param
as URI parameter in the To header ?
E.g.
To: <sip:97775551000 at 45.60.51.41;transport=tcp>
Should it copy this URI parameter in the To header when it forms the
response ?
Also should it also copy this URI param into the From header
when it has to
send subsequent requests within this dialog ?
RFC 3261 stats that when forming responses, "If the To header
field in the
request did not contain a tag, the URI in the To header field in the
response MUST equal the URI in the To header field"
"The From URI of the request MUST be set to the local URI
from the dialog
state"
How should the URI parameters be handled in this regard ?
Any inputs would be appreciated.
Thanks
-Biju
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Paul Kyzivat
2007-08-02 00:08:54 UTC
Permalink
I haven't gone back to study 3261 specifically about this, but based on
my understanding I think:

The sender of an out of dialog request must ensure that there is no tag
in the To-URI. Depending on where the URI came from it may be necessary
to remove the tag. (When creating new out of dialog that are intended to
address the same party you have/had a dialog with, it may often be
reasonable to use the To/From URI of the peer in the dialog.)

The recipient of a request must then add a tag to the To-URI when
sending the response.

Other than that, I believe both parties should be leaving the URIs
unchanged when copying them to the From and To headers of future
requests in a dialog, or out of one. If there are inappropriate
parameters that is a problem for the source of the URI.

Note that when sending an out of dialog request that is intended to
target the peer in a dialog, you will typically want to use the target
(contact) URI of the peer from the dialog as the R-URI. What you put in
the To-URI in that case isn't so clear. You could put the same as in the
R-URI, or you might use the To/From of the dialog peer for it.

Paul



So if those URIs have parameters, those parameters should remain.
Post by Singh, Indresh (SNL US)
Manju is correct that transport parameter should not be present in the
from and to header as per table-1 of RFC-3261.
Page 151 also suggest that Elements processing URI should ignore any
disallowed components if they are present.
But I am not sure if the transport parameter in the from header ( which
is not allowed ) should be ignored while populating the local target uri
information in dialog.
Paul could you kindly comment on this ??
Regards,
Indresh K Singh
-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu
[mailto:sip-implementors-bounces at lists.cs.columbia.edu] On
Behalf Of ext Manjunath Warad
Sent: Wednesday, August 01, 2007 1:39 AM
To: 'Biju Kayakal'; sip-implementors at lists.cs.columbia.edu
Subject: Re: [Sip-implementors] URI parameter in To and From headers
Hi Biju,
RFC recommends not to add transport param in From and To header.
However, if the end-point receives transport param then that
param should be
ignored.
However about creation of responses, if the request is dialog
creating then
1. From header is clone as in request, drop all the
unnecessary info like
transport param if any in request.
2. To header too is clone as in request, dropping all
unnecessary info like
trans param and this end-point has to generate To tag.
Further mid-dialog request MUST carry the same From and To
header in reverse
order with tags intact if generated from callee point.
If the request is not dialog creating one then To tag MUST
NOT be generated.
For the information about the parameters in the URI you can
look into Table
1 from RFC 3261.
Regards,
Manju
**************************************************************
**************
***********
This e-mail and attachments contain confidential information
from HUAWEI,
which is intended only for the person or entity whose address
is listed
above. Any use of the information contained herein in any way
(including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please
notify the sender by
phone or email immediately and delete it!
-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu
[mailto:sip-implementors-bounces at lists.cs.columbia.edu] On
Behalf Of Biju
Kayakal
Sent: Wednesday, August 01, 2007 3:39 AM
To: sip-implementors at lists.cs.columbia.edu
Subject: [Sip-implementors] URI parameter in To and From headers
Hi All,
A SIP endpoint receives a request containing the
transport param
as URI parameter in the To header ?
E.g.
To: <sip:97775551000 at 45.60.51.41;transport=tcp>
Should it copy this URI parameter in the To header when it forms the
response ?
Also should it also copy this URI param into the From header
when it has to
send subsequent requests within this dialog ?
RFC 3261 stats that when forming responses, "If the To header
field in the
request did not contain a tag, the URI in the To header field in the
response MUST equal the URI in the To header field"
"The From URI of the request MUST be set to the local URI
from the dialog
state"
How should the URI parameters be handled in this regard ?
Any inputs would be appreciated.
Thanks
-Biju
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Dale.Worley
2007-08-01 21:07:28 UTC
Permalink
From: "Biju Kayakal" <bijuka at nortel.com>

A SIP endpoint receives a request containing the transport
param as URI parameter in the To header ?
E.g.
To: <sip:97775551000 at 45.60.51.41;transport=tcp>

Should it copy this URI parameter in the To header when it forms the
response ?
Also should it also copy this URI param into the From header when it has
to send subsequent requests within this dialog ?

Yes. But the From and To headers are nearly comments, so their values
do not matter much.

As for Table 1 in RFC 3261, it is not to be trusted -- the From and To
URIs should be allowed to be general, as sometimes that is required to
carry the needed meaning.

Dale
Continue reading on narkive:
Loading...