13 Mar
2003
13 Mar
'03
8:52 p.m.
Hello David,
The spec doesn't say anything about how a new Request-URI should be
constructed for requests being forwarded.
SER simply replaces Request-URI with contact registered by user and
forwards it, that's not a bug, that was intentional. The new Request-URI
is a completely new one so it imho makes no sense to copy some parameters
from the old one (this may potentially lead to a conflict).
You can add another header field or use the body if you need to pass
some information to the other side. Request-URI is not very good place
for such data because it will be rewritten in each proxy along the path.
regards, Jan.
On 13-03 18:01, David.Rio(a)alcatel.fr wrote:
Hello all
I am using SER as a proxy server.
Please let's consider the following scenario
1/ Step 1
A UAC registers to SER
---------
| SER |
---------
^
| REGISTER for 'service(a)logical-element.domain' contact
'service@host'
|
|
---------
| UAC |
---------
2/ Step 2
Another UAC tries to reach the previously registered user BUT WITH
PRIVATE PARAMETERS in request URI
----------
| UAC |
----------
|
|
INVITE service(a)logical-element.domain;param1=value1;param2=value2
v
---------
| SER |
---------
|
| INVITE service@host (sol 1)
| or INVITE service@host;param1=value1;param2=value2 (sol 2)
v
---------
| UAC |
---------
The translation from service(a)logical-element.domain to service@host is
done in SER using 'lookup'.
3/ Problem :
I observe that SER when translating the user@host part of the request
URI does not recopy the private parameters,
what I expected it to do.
=> I can not find any clear position in RFC 3261 (from my understanding
of the RFC).
Is it a bug in SER or does SER really implement the behaviour a standard
SIP proxy should have ?
Thanks for your answers
--
David Rio
Alcatel CIT - Rennes
ASD France
33 2 99 87 47 18
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers